Critical Splunk Enterprise Bug Opens a Path to Pre-Auth Remote Code Execution

Splunk has patched a critical vulnerability in Splunk Enterprise that deserves fast attention from administrators because the weak point sits before authentication and can be reached over the network when exposed. The flaw, tracked as CVE-2026-20253, carries a CVSS score of 9.8 and affects specific Splunk Enterprise 10.x releases that use a PostgreSQL sidecar service.

According to Splunk’s security alert, the affected endpoint lacks authentication controls, allowing a network-reachable user to create or truncate arbitrary files. That phrasing may sound like a file-handling issue, but the practical risk is higher. Research from watchTowr Labs describes a path from unauthenticated access to controlled file write, then to pre-authenticated remote code execution on vulnerable deployments.

The affected platforms are narrow but important:

• Splunk Enterprise 10.0.0 through 10.0.6, fixed in 10.0.7
• Splunk Enterprise 10.2.0 through 10.2.3, fixed in 10.2.4
• Splunk Enterprise 10.4, not affected
• Splunk Cloud, not affected, because Splunk says the impacted PostgreSQL sidecars are not used there

Administrators should treat this as an urgent patching item if Splunk Enterprise management or sidecar interfaces are reachable from anything broader than a tightly controlled admin network.

What Happened

The vulnerable component is tied to Splunk Enterprise’s PostgreSQL sidecar service. Splunk said an unauthenticated user could perform arbitrary file operations through that sidecar endpoint because the endpoint did not enforce authentication before accepting requests.

watchTowr’s analysis adds the more operationally useful detail: the exposed functionality involves PostgreSQL recovery endpoints, including /v1/postgres/recovery/backup and /v1/postgres/recovery/restore. In the researchers’ chain, those endpoints can be used to interact with an attacker-controlled PostgreSQL database, place files on the Splunk host, restore attacker-controlled SQL into the local PostgreSQL instance, and finally write malicious content into a file Splunk executes.

That chain matters because many defenders mentally separate “file write” from “code execution.” In enterprise software, the gap between the two can be small. If an attacker can write to a location that is later loaded as configuration, interpreted as code, executed as a script, or consumed by a privileged service, file write becomes an execution primitive.

In this case, the reported technique uses PostgreSQL behavior as the bridge. PostgreSQL supports large object operations, including lo_export, which can write database object contents to the filesystem. If an attacker can get controlled SQL restored into the local database context, the database engine may become the mechanism for writing attacker-selected content onto disk.

Expert Context

Splunk’s own advisory language is direct: the vulnerable sidecar endpoint “lacks authentication controls.” That is the central security failure. The endpoint performs sensitive operations but accepts requests from network-reachable users without first proving identity.

watchTowr researchers Piotr Bazydlo and Yordan Ganchev described the critical turning point in practical terms: once they could restore attacker-controlled SQL into the local PostgreSQL instance, they had a controlled file write. That is the kind of finding security teams should read as more than a proof of concept. It shows that the bug is not just theoretical misuse of an API. It is a chainable weakness in a privileged operational path.

The broader lesson is familiar across enterprise platforms: internal service endpoints often start as trusted plumbing, then become attack paths when network boundaries shift. A sidecar service may be designed for local orchestration, recovery, clustering, or administrative workflows. If that service is reachable beyond the expected trust zone and does not authenticate its callers, the deployment inherits a remote attack surface that may not appear in normal user-facing documentation.

Splunk is also a high-value target because of what it typically contains. Splunk Enterprise instances often process logs from identity systems, cloud infrastructure, endpoint agents, firewalls, VPNs, developer platforms, and business applications. Code execution on a Splunk server can give an attacker more than control of one application. It can expose credentials, tokens, indexed security telemetry, alerting logic, saved searches, and integrations used by security operations teams.

That makes this vulnerability especially sensitive in incident response environments. A compromised logging platform can help an attacker understand what defenders can see, suppress or alter evidence, and pivot toward systems that trust Splunk integrations.

How the Attack Chain Works

The public technical write-up describes a multi-stage chain rather than a single magic request.

First, the attacker prepares a PostgreSQL database under their control. That database is configured so the vulnerable Splunk endpoint can connect and interact with it. The attacker then uses the backup endpoint to dump content from the attacker-controlled database into an arbitrary file on the Splunk filesystem.

Next, the restore endpoint is used to load a malicious database dump into Splunk’s local PostgreSQL instance. A key detail is the use of a passfile argument pointing at a .pgpass file on the Splunk host, reportedly /opt/splunk/var/packages/data/postgres/.pgpass. That file contains credentials for the postgres_admin user. If the endpoint accepts the supplied path and uses it during restore, the attacker can make Splunk’s own environment provide the authentication material needed for local database access.

Once attacker-controlled SQL is restored locally, PostgreSQL features become part of the exploit surface. The researchers describe using a function such as lo_export to write attacker-controlled content from the database to a file on disk.

The final step is turning controlled file write into code execution. The reported path overwrites a Python script that Splunk executes, such as a script under /opt/splunk/etc/apps/splunk_secure_gateway/bin/. When Splunk later runs that script, the attacker’s payload runs in the Splunk application context.

That sequence is a good example of why defenders should not evaluate critical bugs only by the first primitive. “Unauthenticated file operation” may sound less urgent than “remote shell,” but a mature exploit chain combines reachable APIs, local credential files, database restore behavior, script execution paths, and predictable filesystem layout.

Why This Matters

There is no public evidence in the provided reporting that CVE-2026-20253 has been exploited in the wild, but exploit detail changes the risk calculation. Once researchers publish endpoint names, filesystem paths, and a working exploitation strategy, defenders should assume scanning and opportunistic testing will follow.

Splunk servers are also not always isolated as tightly as teams believe. Some deployments expose management interfaces to internal networks, shared administrative VPNs, jump hosts, monitoring networks, or cloud security groups that have grown over time. An attacker who has already gained a foothold through phishing, stolen VPN credentials, a vulnerable edge service, or a compromised developer system may not need internet exposure. Internal reachability can be enough.

This is especially relevant because the flaw is pre-authentication. Network controls become the main barrier before patching. If a vulnerable endpoint is reachable from an attacker’s position, the attacker does not need a Splunk user account, stolen session, API token, or valid SSO path to begin the chain.

Practical Advice for Defenders

Patch first. Splunk Enterprise 10.0 deployments should move to 10.0.7 or later, and Splunk Enterprise 10.2 deployments should move to 10.2.4 or later. Teams should monitor the Splunk advisory portal and Splunk release channels for any follow-up guidance.

Reduce network reachability while patching is in progress. Restrict access to Splunk management and sidecar service interfaces to trusted administrative hosts only. If segmentation is already in place, verify it with actual connection tests rather than relying on diagrams or intended firewall policy.

Search for exposure of the reported endpoints. Review reverse proxies, load balancers, ingress controllers, firewall rules, Kubernetes services, cloud security groups, and host listeners for paths or services that could expose /v1/postgres/recovery/backup or /v1/postgres/recovery/restore beyond the local trust boundary.

Inspect Splunk hosts for suspicious file changes. Pay special attention to Splunk app directories, Python scripts, modular inputs, and files modified around the time suspicious requests may have occurred. The example path from the research, /opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py, should be treated as one possible target, not the only one.

Review logs for unauthenticated access to PostgreSQL recovery endpoints. Web access logs, Splunk internal logs, reverse proxy logs, EDR telemetry, and host audit records may show unexpected requests to backup or restore routes. Look for requests from non-administrative hosts, unusual user agents, unexpected POST bodies, and restore operations that reference local credential files.

Check for unexpected PostgreSQL activity. If available, review PostgreSQL logs for restore activity, large object operations, suspicious function creation, or commands that write to the filesystem. PostgreSQL’s large object documentation is useful background for understanding why database features can become file-write primitives in this kind of chain.

Rotate credentials if compromise is suspected. If a vulnerable Splunk host may have been exploited, assume local secrets, app credentials, service account tokens, and integration keys could have been exposed. Prioritize credentials used by Splunk to reach cloud services, ticketing systems, SOAR platforms, identity providers, data sources, and alert delivery channels.

What Security Teams Should Change

This incident is a reminder to inventory internal service endpoints, not just public web interfaces. Recovery, backup, migration, and maintenance APIs often have powerful behavior because they are designed for administrators and automation. They should require authentication, enforce authorization, and be bound to the smallest practical network scope.

It also argues for treating observability platforms as privileged infrastructure. Splunk is not just a log viewer in many organizations. It is part of detection, investigation, compliance, and operational response. A compromise there can affect both visibility and control.

For mature teams, the follow-up work should include three checks. First, confirm the fixed Splunk Enterprise version everywhere, including standby nodes, test systems, and forgotten admin instances. Second, validate that management and sidecar interfaces are not broadly reachable. Third, build detection for unexpected writes into Splunk app directories and unusual execution of scripts under Splunk-managed paths.

CVE-2026-20253 is narrow in version scope, but serious in impact. The fix is available, Splunk Cloud is not affected, and Splunk Enterprise 10.4 is listed as not affected. For everyone else running the vulnerable 10.0 or 10.2 branches, this is a patch-now issue, followed by exposure review and focused threat hunting.