CVE-2026-20253: Splunk Enterprise Unauthenticated RCE Explained

TL;DR

A critical vulnerability tracked as CVE-2026-20253 (CVSS 9.8) in Splunk Enterprise allows a completely unauthenticated, network-reachable attacker to create or truncate arbitrary files on the underlying server through an exposed PostgreSQL sidecar service. Security researchers at WatchTowr Labs chained this primitive into full remote code execution, no login, no API token, no prior access required.

The issue is fixed in Splunk Enterprise 10.4.0, 10.2.4, and 10.0.7. There is no workaround. If you run a vulnerable version, especially on AWS, patching is the only fix.

What Is CVE-2026-20253?

CVE-2026-20253 was published by Splunk on June 10, 2026 as advisory [SVD-2026-0603](https://advisory.splunk.com/advisories/SVD-2026-0603) and assigned a CVSS v3.1 score of 9.8 (Critical), with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Translated out of CVSS notation: the attack is launched over the network, requires low complexity, needs zero privileges, needs zero user interaction, and can fully compromise confidentiality, integrity, and availability.

The root cause is classified as CWE-306, Missing Authentication for Critical Function. A backend service that Splunk Enterprise bundles for PostgreSQL backup and restore operations exposes HTTP API endpoints that perform file system operations and accept absolutely no credentials. Splunk's own web application then proxies requests to that service, which means anyone who can reach the Splunk web port can reach the unauthenticated backend too.

The vulnerability was credited to researcher Alex Hordijk (hordalex), and a detailed technical writeup was published by [WatchTowr Labs](https://labs.watchtowr.com/why-use-app-level-auth-when-every-database-has-auth-splunk-enterprise-cve-2026-20253-pre-auth-rce/) showing how the file-write primitive escalates all the way to code execution.

Why Splunk Has a PostgreSQL Sidecar Service

Newer Splunk Enterprise builds, particularly the AWS-deployed editions, ship with a bundled PostgreSQL database used by certain Splunk components for internal storage. To manage that database, Splunk runs a small PostgreSQL Sidecar Service, a Go binary that listens on localhost:5435 and exposes a local HTTP API for backup and restore operations.

Binding to localhost is normally a reasonable control: only processes on the same host can talk to it directly. The problem is that Splunk's main web application (splunkd, listening on port 8000) proxies external requests straight through to that local API via paths like:

/en-US/splunkd/__raw/v1/postgres/recovery/backup
/en-US/splunkd/__raw/v1/postgres/recovery/restore

Neither the sidecar's local API nor the proxy path performs any authentication check. Any request that reaches Splunk's main web port, including from an attacker with zero credentials, is forwarded straight to a service that can read, write, and truncate files on disk.

The Attack Chain: From Anonymous Request to Code Execution

On its own, "create or truncate arbitrary files" sounds like a denial-of-service bug, you could destroy critical config files. WatchTowr Labs showed it is far worse: the same primitive can be escalated step by step into arbitrary code execution as the splunk user. Step by step, the published research describes:

1. Arbitrary file create/truncate. A crafted request to the /backup endpoint with a path-traversal sequence in the backupFile parameter causes pg_dump to write an empty file to an attacker-chosen path anywhere on the filesystem.
2. Connection string injection. The database parameter is passed straight into PostgreSQL connection strings. By injecting hostaddr=attacker-controlled-ip, the sidecar's pg_dump/pg_restore calls connect to a rogue PostgreSQL server the attacker controls, despite a hardcoded -h localhost flag.
3. Local credential discovery. Using the same file-read style traversal, the researchers located Splunk's local PostgreSQL credentials in /opt/splunk/var/packages/data/postgres/.pgpass, including the postgres_admin account.
4. Authenticated local access. Passing passfile=/opt/splunk/var/packages/data/postgres/.pgpass in the connection string lets the attacker's restore operation authenticate to Splunk's own local PostgreSQL instance as postgres_admin.
5. Malicious SQL payload. The attacker serves a crafted database dump containing a PL/pgSQL function that calls lo_export() to write attacker-controlled bytes to an arbitrary path on disk.
6. Code execution. The /restore endpoint executes that function and overwrites /opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py with malicious Python. Splunk periodically runs this file as part of its modular input lifecycle, executing the attacker's code as the splunk service account.

No part of this chain requires a username, password, API token, or any interaction from a logged-in user. The only requirement is network reachability to Splunk's web interface.

Why This Hits AWS Deployments Hardest

The PostgreSQL sidecar is enabled by default on Splunk Enterprise on AWS (the AWS Marketplace / Quick Start deployment), while it is typically not enabled on manually installed on-premises instances such as standard Windows installs. That makes cloud-deployed Splunk Enterprise instances exposed out of the box, with no extra configuration needed to introduce the vulnerable service.

If your Splunk Enterprise web interface is reachable from the internet, or even from a broad internal network segment, on a version in the affected range, this is effectively a pre-authenticated remote code execution vulnerability against your SIEM.

Affected and Fixed Versions

Splunk's official advisory [SVD-2026-0603](https://advisory.splunk.com/advisories/SVD-2026-0603) lists the 10.2.x and 10.0.x ranges above as affected. Some third-party analyses (Orca Security) also flag earlier 9.3.x and 9.4.x branches as exposed, with fixes landing in 9.4.12 and 9.3.13. If you run a 9.x branch, check the advisory directly for your exact build and apply the latest maintenance release for that branch regardless.

There is no workaround or mitigating configuration. Upgrading is the only fix Splunk has published.

Is Splunk Cloud Platform Affected?

When SVD-2026-0603 was first published on June 10, 2026, some early write-ups flagged Splunk Cloud Platform builds as affected. Splunk updated the advisory on June 12, 2026 to clarify that Splunk Cloud Platform does not use the PostgreSQL sidecar architecture and is not affected by CVE-2026-20253. If you are a Splunk Cloud customer, no action is required for this specific CVE, though it is still worth confirming with your Splunk account team and checking the advisory for any other items in the same batch that do apply to Cloud Platform.

Other Vulnerabilities Patched in the Same Advisory Batch

CVE-2026-20253 was published alongside several other Splunk Enterprise fixes on June 10, 2026, including:

• CVE-2026-20251, a remote code execution issue caused by deserialization of untrusted data in the Splunk Secure Gateway app.
• CVE-2026-20204, a separate high-severity remote code execution flaw affecting Splunk Enterprise and Splunk Cloud Platform.
• Multiple stored cross-site scripting (XSS) and server-side request forgery (SSRF) issues across Splunk Enterprise apps.

None of these carry the same "zero authentication required" severity as CVE-2026-20253, but they are part of the same patch cycle. If you are scheduling an upgrade window for CVE-2026-20253, pull in the full advisory list from [advisory.splunk.com](https://advisory.splunk.com) and patch everything in the batch at once.

MITRE ATT&CK Mapping

For defenders building detections around this vulnerability, the attack chain maps to several well-known techniques:

How to Detect Exploitation Attempts

Even after patching, it is worth checking whether a vulnerable instance was already probed or exploited:

• Web access logs. Search web_access.log and splunkd_access.log for unauthenticated POST requests to /en-US/splunkd/__raw/v1/postgres/recovery/backup or /en-US/splunkd/__raw/v1/postgres/recovery/restore. Any hit on these paths from an external or unexpected internal IP is a strong indicator of probing.
• Unexpected outbound PostgreSQL connections. The connection-string injection step forces pg_dump/pg_restore to connect to an attacker-controlled host. Network logs showing the Splunk host initiating outbound connections on PostgreSQL's default port (5432) to unfamiliar external IPs are a red flag.
• File integrity on key paths. Check the modification time and contents of /opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py and the contents of /opt/splunk/var/packages/data/postgres/.pgpass. Any unexpected change to either file, especially outside a maintenance window, warrants investigation.
• Unexpected files in writable paths. Look for new or zero-byte files created outside normal Splunk operations, particularly under /tmp and Splunk's app directories, which would indicate the file-creation primitive was used.

How to Protect Your Splunk Environment

1. Patch immediately

Upgrade to Splunk Enterprise 10.4.0, 10.2.4, or 10.0.7, whichever matches your current major branch, or to the latest maintenance release if you are on an older 9.x branch. This is the only complete fix, and Splunk has not published a configuration-based workaround.

2. If you cannot patch today

While you schedule the upgrade window:

• Restrict network access to the Splunk web port (8000) to known management networks only. Do not expose it to the public internet.
• Place a reverse proxy or WAF in front of Splunk that explicitly blocks requests to /en-US/splunkd/__raw/v1/postgres/recovery/backup and /en-US/splunkd/__raw/v1/postgres/recovery/restore.
• If you deployed via the AWS Marketplace edition and do not actively use the PostgreSQL-backed features, work with Splunk support to confirm whether the sidecar service can be disabled in your specific deployment.

3. Rotate credentials after patching

Because the attack chain relies on reading .pgpass to obtain the postgres_admin password, rotate that credential after upgrading, even if you find no evidence of exploitation. Treat any credential that could have been exposed through this path as compromised.

4. Audit your wider Splunk attack surface

This vulnerability is a reminder that SIEM platforms are high-value targets precisely because they aggregate sensitive logs and often run with broad internal network access. If you are evaluating how Splunk's architecture compares to alternatives, our [Microsoft Sentinel vs Splunk comparison](/blog/microsoft-sentinel-vs-splunk-siem-comparison) covers architecture and operational tradeoffs, and our [SIEM vs SOAR vs XDR guide](/blog/siem-vs-soar-what-is-the-difference) explains how these platforms fit into a broader detection and response stack.

Frequently Asked Questions

What is CVE-2026-20253?

CVE-2026-20253 is a critical (CVSS 9.8) vulnerability in Splunk Enterprise where a PostgreSQL sidecar service exposes unauthenticated HTTP endpoints that perform file create and truncate operations. Researchers extended this into full remote code execution without any login.

Which Splunk Enterprise versions are affected?

Splunk Enterprise versions 10.2.0 through 10.2.3 and 10.0.0 through 10.0.6 are listed as affected in the official advisory SVD-2026-0603. The fixes are in 10.4.0, 10.2.4, and 10.0.7. Some 9.3.x and 9.4.x builds may also be affected; check the advisory for your exact version.

Is Splunk Cloud Platform affected by CVE-2026-20253?

No. Splunk updated its advisory on June 12, 2026 to confirm that Splunk Cloud Platform does not use the PostgreSQL sidecar architecture and is not affected by this CVE.

Is there a workaround if I cannot patch right away?

Splunk has not published a configuration workaround. The only complete fix is upgrading. As a temporary measure, restrict network access to the Splunk web port and block requests to the /v1/postgres/recovery/backup and /v1/postgres/recovery/restore paths at a reverse proxy or WAF.

Why is this especially risky for Splunk Enterprise on AWS?

The PostgreSQL sidecar service is enabled by default on Splunk Enterprise on AWS deployments, while it is typically not enabled on manual on-premises installs. AWS-deployed instances are exposed to this issue without any extra configuration.

Does exploiting this vulnerability require any credentials?

No. The CVSS vector (PR:N, UI:N) confirms no privileges and no user interaction are required. Any attacker who can reach the Splunk web interface over the network can attempt exploitation.

Conclusion

CVE-2026-20253 is the kind of vulnerability that should move to the top of every Splunk administrator's patch queue: a 9.8 CVSS score, zero authentication required, and a documented path to full remote code execution on the very system you rely on to detect attacks elsewhere in your environment. If you run Splunk Enterprise 10.2.x below 10.2.4 or 10.0.x below 10.0.7, especially on AWS, treat this as an active incident response item, not a routine patch cycle. Upgrade first, then audit logs for signs the sidecar endpoints were already probed, and rotate the PostgreSQL credentials referenced in the attack chain regardless of what you find.

It joins a growing list of 2026 incidents that started with one overlooked credential or exposed service: our breakdown of [the Vercel supply chain breach](/blog/vercel-breach-2026-supply-chain-attack-analysis) shows the same pattern playing out through a stolen OAuth token instead of a sidecar API.