Critical Splunk Enterprise Flaw (CVE-2026-20253) Under Active Exploitation: Pre-Auth RCE via PostgreSQL Sidecar

A critical vulnerability in Splunk Enterprise — the workhorse logging and SIEM platform that sits at the heart of countless enterprise security operations centers — is being actively exploited in the wild, allowing unauthenticated attackers to seize complete control of affected servers. Tracked as CVE-2026-20253, the flaw carries a CVSS score of 9.8 (Critical) and was added to the U.S. Cybersecurity and Infrastructure Security Agency's (CISA) Known Exploited Vulnerabilities (KEV) catalog on June 18, 2026, triggering federal patching mandates and amplifying the urgency for private-sector defenders.

What Happened

On June 10, 2026, Splunk's Product Security Incident Response Team (PSIRT) published advisory SVD-2026-0603, disclosing that an unauthenticated attacker could create or truncate arbitrary files on Splunk Enterprise hosts via an undocumented PostgreSQL "sidecar" service endpoint. The vendor's initial framing was relatively conservative — describing the issue as arbitrary file creation and truncation stemming from missing authentication (CWE-306) — but the severity score telegraphed that something far more dangerous was lurking beneath the surface.

That suspicion was confirmed days later when researchers at watchTowr Labs published a detailed technical analysis and proof-of-concept demonstrating that the vulnerability could be reliably chained into unauthenticated pre-authentication Remote Code Execution (RCE). The watchTowr write-up — titled "Why Use App-Level Auth When Every Database Has Auth?" — walks through how PostgreSQL's own connection string parsing quirks, combined with hardcoded credential files shipped inside Splunk, transform a seemingly contained file-write primitive into full system compromise as the splunk user.

The vulnerability was discovered and reported by researcher Alex Hordijk (hordalex), according to Splunk's credits. By June 18, 2026, CISA had added CVE-2026-20253 to the KEV catalog, citing active exploitation with the technical impact assessed as "total" and exploitation marked as "automatable: yes" — a combination that effectively guarantees mass scanning and opportunistic compromise.

For an organization, a compromised Splunk server is a worst-case scenario: it is the system that holds the logs you would normally use to detect an intrusion, contains credentials and API keys for the rest of the environment, and often has privileged network reach into otherwise-segmented zones.

Understanding the Vulnerability

At its core, CVE-2026-20253 is a missing-authentication bug (CWE-306) in a PostgreSQL "sidecar" service that Splunk Enterprise 10.x bundles to support features like Edge Processor, OpAmp, and SPL2 data pipelines. The sidecar runs locally on 127.0.0.1:5435, but — and this is the crucial design flaw — the main Splunk web application (splunkd, listening on port 8000) proxies HTTP requests to the sidecar without enforcing authentication on a specific set of recovery API endpoints.

The two endpoints that matter are:

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

These endpoints accept two JSON parameters — database and backupFile — and pass them more or less directly into the command-line arguments of pg_dump and pg_restore. While the developers hardcoded a -h localhost flag intending to constrain the database host to the local machine, PostgreSQL's libpq client library has a delightful (for attackers) feature: the database argument can itself be a full connection string, and parameters parsed from that string override earlier command-line arguments.

That means an attacker can stuff a hostaddr=<attacker-ip> directive into the database parameter and force pg_dump to connect to a remote, attacker-controlled PostgreSQL server. They can also inject passfile=/opt/splunk/var/packages/data/postgres/.pgpass — pointing at a hardcoded Splunk credentials file shipped with the install — to authenticate locally without ever knowing a real password.

From there, the attacker abuses PostgreSQL's lo_export SQL function, which writes the contents of a "large object" to an arbitrary file on the database server's filesystem. Combine that with the ability to control which SQL gets restored, and you have an arbitrary file write executing as the splunk system user.

The Attack Chain, Step by Step

Based on the watchTowr Labs technical analysis, the full exploitation chain unfolds as follows:

1. Reconnaissance: The attacker identifies a Splunk Enterprise 10.x instance exposing port 8000. A quick probe of /en-US/splunkd/__raw/v1/postgres/recovery/backup with an empty Basic Auth header returns an HTTP 400 on vulnerable systems (versus HTTP 401 on patched ones), confirming the target.
2. Staging: The attacker stands up a remote PostgreSQL server configured with passwordless authentication in pg_hba.conf. On this server, they create a database containing a malicious SQL function that uses lo_export to write attacker-supplied bytes to a chosen file path.
3. Backup Injection (Pull the Payload): The attacker sends a POST request to /en-US/splunkd/__raw/v1/postgres/recovery/backup with empty Basic Auth credentials. The database JSON field contains hostaddr=<ATTACKER_IP>, forcing pg_dump to connect to the attacker's PostgreSQL instance. The backupFile parameter specifies a local path on the Splunk server (e.g., somewhere under /tmp or /opt/splunk/var/run/supervisor/pkg-run/) where the malicious dump is written.
4. Restore Injection (Execute the Payload): The attacker sends a second POST to /en-US/splunkd/__raw/v1/postgres/recovery/restore, this time setting database to dbname=template1 passfile=/opt/splunk/var/packages/data/postgres/.pgpass. This bypasses local PostgreSQL authentication using Splunk's own bundled credentials. The backupFile parameter points to the dump staged in Step 3.
5. File Write via lo_export: As PostgreSQL replays the dump, it executes the embedded lo_export call, writing the attacker's payload — typically a Python script — to a sensitive location on disk. A favored target is , a modular input script that Splunk executes regularly.

Notably, the Splunk Cloud Platform is not affected because it does not use the PostgreSQL sidecar architecture. Splunk Enterprise 9.4 and earlier are also unaffected — the sidecar was introduced in the 10.x line. And crucially, Splunk Enterprise on AWS ships with the sidecar enabled by default, making AWS-hosted deployments especially exposed out of the box.

Who Is Affected

Splunk is deployed in tens of thousands of enterprises worldwide, ranging from Fortune 500 companies and government agencies to managed security service providers. As a centralized data platform, it typically aggregates logs from across an organization's entire IT estate — endpoints, servers, network devices, cloud workloads, identity providers — making it a uniquely valuable target. A compromised Splunk instance is, effectively, a master key to understanding (and potentially erasing evidence of) activity across the rest of the environment.

AWS deployments warrant special attention: because the PostgreSQL sidecar is enabled by default in the Splunk Enterprise on AWS distribution, any unpatched 10.x AWS deployment is vulnerable without any additional configuration.

Real-World Risk

The risk profile here is about as bad as it gets for an enterprise security tool:

• Active in-the-wild exploitation: Splunk PSIRT updated its advisory on June 18, 2026 to confirm limited active exploitation, and CISA added the CVE to the KEV catalog the same day.
• Public, weaponizable proof-of-concept: watchTowr Labs has published both detection logic and exploitation primitives on GitHub (watchtowrlabs/watchTowr-vs-Splunk-CVE-2026-20253), dramatically lowering the bar for opportunistic attackers.
• Automatable: CISA's SSVC assessment lists exploitation as automatable: yes with Technical Impact: total — a combination that historically correlates with mass scanning within days.
• Pre-authentication: No credentials, no user interaction, no special privileges. If port 8000 is reachable, the box is reachable.

If attackers achieve RCE as the splunk user, the worst-case scenarios include:

• Mass log exfiltration: Splunk indexes are often a treasure trove of credentials, session tokens, internal hostnames, and sensitive business data inadvertently logged by applications.
• Tampering with security monitoring: Attackers could alter or delete SIEM alerts, modify detection rules, and erase forensic evidence of their own activity — effectively blinding the SOC.
• Credential harvesting: Splunk configurations frequently contain API keys, database connection strings, and integration credentials for ticketing systems, threat intel feeds, and cloud APIs.
• Lateral movement: Splunk forwarders are deployed across the environment and often run with elevated privileges. A compromised indexer or search head can become a launchpad into otherwise-segmented network zones.

The identities of threat actors currently exploiting CVE-2026-20253 have not been publicly disclosed, but the combination of automated exploitability and the high value of compromised SIEM infrastructure makes both opportunistic ransomware crews and nation-state actors likely participants.

What You Should Do

1. Patch Immediately

Upgrade affected Splunk Enterprise deployments to one of the following fixed versions, released on June 10, 2026:

• 10.4.0 (the latest branch)
• 10.2.4 (for the 10.2.x branch)
• 10.0.7 (for the 10.0.x branch)

Patches are available via the Splunk advisory at advisory.splunk.com/advisories/SVD-2026-0603 (https://advisory.splunk.com/advisories/SVD-2026-0603). For federal civilian agencies, the KEV listing triggers a binding remediation deadline under BOD 22-01.

2. Apply the Workaround if Patching Will Be Delayed

If you cannot upgrade immediately, Splunk provides a full workaround: disable the PostgreSQL sidecar. Add the following stanza to $SPLUNK_HOME/etc/system/local/server.conf:

1[postgres]
2disabled = true

Then restart Splunk Enterprise.

Important caveat from Splunk: Do not apply this workaround if you use any of the following features, as they depend on the sidecar:

• Edge Processor
• OpAmp
• SPL2 data pipelines

Disabling PostgreSQL will break these features and can cascade to dependent sidecar processes. Core search, indexing, and dashboard functionality are not affected by the workaround.

3. Restrict Network Exposure

As a partial mitigation — and a defense-in-depth measure even after patching — ensure that Splunk Web (port 8000) is not directly exposed to the internet. Place it behind a VPN, identity-aware proxy, or strict ACLs allowing only management VLANs and trusted IP ranges. There is no legitimate reason for a Splunk management UI to be reachable from the public internet.

4. Hunt for Compromise

Given confirmed in-the-wild exploitation, assume any internet-exposed vulnerable instance may already be compromised. Hunt for:

HTTP/Web Log Indicators:

• POST requests to /en-US/splunkd/__raw/v1/postgres/recovery/backup or /en-US/splunkd/__raw/v1/postgres/recovery/restore
• Requests to those endpoints lacking proper Authorization headers but receiving HTTP 200 responses
• Request bodies containing the strings hostaddr=, passfile=, or ../

Process Telemetry:

• pg_dump or pg_restore invocations with unusual -d (database) argument values, especially those containing hostaddr= or passfile=
• Unexpected outbound connections from the Splunk host to external PostgreSQL servers

File System Indicators:

• Unexpected files in /opt/splunk/var/run/supervisor/pkg-run/ or /tmp
• Modifications to Splunk-bundled Python scripts, especially /opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py
• Anomalous use of .pgpass files in database connectivity logs

PostgreSQL Logs:

• Creation of database functions using the lo_export SQL function
• Unexpected connections referencing the bundled .pgpass file

A basic detection logic, drawn from the watchTowr PoC, distinguishes vulnerable from patched instances by response code: an HTTP 400 to an empty-auth POST against the recovery endpoints suggests vulnerability, while an HTTP 401 suggests the patch (or workaround) is in place. This same logic can be used by defenders to inventory exposure across their estate — and by attackers to find targets, which is precisely why patching cannot wait.

5. Rotate Credentials Stored in Splunk

If you have any reason to suspect a compromise — or if your Splunk instance was internet-exposed during the exposure window — rotate any credentials, API keys, or service account passwords stored in Splunk configurations or apps. Assume any data that lived in indexes has been viewed.

The Bigger Picture

CVE-2026-20253 is a textbook example of a recurring architectural anti-pattern: trusting the network boundary instead of authenticating at the application boundary. The PostgreSQL sidecar was designed to listen only on 127.0.0.1, on the implicit assumption that local-only binding constituted sufficient access control. That assumption held until the main splunkd web application began transparently proxying unauthenticated HTTP requests to it — at which point "localhost only" became "anyone with a browser."

The watchTowr Labs analysis title says it bluntly: Why use app-level auth when every database has auth? The answer, of course, is that hardcoded .pgpass files shipped inside the application bundle ensured that the "database auth" was no auth at all from the perspective of anyone who could reach the proxy.

There are two broader lessons here for defenders and developers alike. First, sidecar architectures multiply the attack surface in subtle ways: services that look isolated based on their listening interface can be silently re-exposed by any other component that proxies to them. Second, vendor severity assessments and researcher findings can diverge significantly. Splunk's original advisory framed this as arbitrary file creation and truncation — bad, but bounded. WatchTowr's chain to full RCE demonstrates how thin the line between "arbitrary file write" and "complete system compromise" really is, especially when the writable file system contains scripts the application itself executes. Defenders should generally assume that any unauthenticated file write primitive in a complex application can be escalated, and prioritize accordingly.

Finally, expect more scrutiny of the broader sidecar ecosystem in Splunk and similar platforms. Where one architectural pattern hosts one unauthenticated endpoint, others are often hiding in adjacent code paths. The fact that researchers reached pre-auth RCE in days — and that exploitation followed soon after — suggests this will not be the last critical CVE we see in this class of components. Patch now, segment your management interfaces, and treat your SIEM with the same security rigor as the assets it monitors.