Breaking: Splunk Enterprise Pre-Auth RCE (CVE-2026-20253) — 18 June 2026
Splunk Enterprise Pre-Auth RCE — CVE-2026-20253
CISA added CVE-2026-20253 to its Known Exploited Vulnerabilities catalogue today with a three-day remediation deadline. That timeline is as aggressive as they come, and it reflects the severity: an unauthenticated attacker can create or truncate arbitrary files through a PostgreSQL sidecar service endpoint in Splunk Enterprise, and security researchers have demonstrated the path from file write to full remote code execution.
The vulnerability affects Splunk Enterprise 10.2 versions below 10.2.4 and version 10 versions below 10.0.7. Versions 9.4 and earlier are unaffected because the PostgreSQL sidecar was introduced in version 10. On AWS deployments, the sidecar is installed and enabled by default, making those instances vulnerable out of the box. On-premises Windows installs default to disabled.
Splunk rates this CVSS 9.8. Watchtowr published detailed analysis showing the vulnerability is reachable through Splunk's main web interface on port 8000, which proxies requests to the PostgreSQL sidecar on localhost:5435. The attack requires no authentication, no user interaction, and no special privileges. An attacker who can reach the Splunk web port can trigger file creation or truncation, and from there escalate to code execution.
What This Means
Splunk Enterprise is the core SIEM and log aggregation platform for a substantial portion of the enterprise market. An unauthenticated RCE in a product that organisations trust to detect breaches is the kind of vulnerability that threat actors prioritise. If your SIEM is compromised, your detection capability is not just degraded; it may be actively misleading you.
The three-day KEV deadline (June 21) is not advisory. CISA considers this actively exploited in the wild. The watchtowr proof-of-concept is public. The window between disclosure and weaponised exploitation is effectively closed.
So What / Action
Patch immediately to Splunk Enterprise 10.2.4, 10.0.7, or 10.4.0. If patching within three days is not possible, disable the PostgreSQL sidecar by adding `[postgres]\ndisabled = true` to `$SPLUNK_HOME/etc/system/local/server.conf` and restarting. Note that disabling PostgreSQL breaks Edge Processor, OpAmp, and SPL2 data pipelines. Core search, indexing, and dashboards are unaffected.
Audit Splunk instances for signs of exploitation. Look for unexpected file creation in Splunk directories, unusual POST requests to `/en-US/splunkd/__raw/v1/postgres/` endpoints, and any anomalous process execution originating from the splunk-postgres binary. If you run Splunk on AWS, assume default exposure and prioritise accordingly.