By The tool monitoring your infrastructure for attacks just became the attack. CVE-2026-20253 is a CVSS 9.8 critical vulnerability in Splunk Enterprise — unauthenticated, pre-auth remote code execution, no credentials needed. CISA added it to the Known Exploited Vulnerabilities catalog on June 18. Active exploitation has been confirmed since June 15. If you’re running Splunk Enterprise 10.2.x or 10.0.x and haven’t patched, you’re exposed right now.
What Broke
The flaw lives in a PostgreSQL sidecar service that Splunk added in recent major versions to power Edge Processor, OpAmp management, and SPL2 data pipelines. This sidecar runs a small HTTP API — and that API has no authentication whatsoever. Because Splunk’s main web interface proxies requests internally, any attacker who can reach Splunk’s web port (8000 or 8089) can reach these endpoints, including from outside the network if your Splunk instance faces the internet.
The official Splunk advisory calls it “unauthenticated arbitrary file creation and truncation.” Security firm watchTowr published the full story two days after the patch: the file-write primitive chains into complete pre-auth RCE. The attack sends crafted requests to the /splunkd/__raw/v1/postgres/recovery/backup endpoint, redirects pg_dump/pg_restore calls to an attacker-controlled PostgreSQL server via connection string injection, then uses PostgreSQL’s lo_export function to overwrite Python scripts that Splunk regularly executes. When Splunk re-runs those scripts, attacker code runs in the Splunk process context. watchTowr titled their writeup “Why Use App-Level Auth When Every Database Has Auth?” — which is the charitable version of what happened here.
Why Attacking a SIEM Is Uniquely Catastrophic
Most critical RCEs give attackers a foothold. Attacking Splunk gives them a command center. Splunk Enterprise is a SIEM — it ingests logs from your firewalls, servers, authentication systems, applications, and cloud environments. An attacker with RCE on Splunk now has:
- Full visibility into your security alerts and detection rules — they know exactly what you can and can’t see
- Access to all historical log data, including credentials that appear in error messages, tokens in API logs, and internal network topology
- The ability to delete or forge log entries, eliminating forensic evidence and poisoning your investigation
- Real-time awareness of your incident response as you respond to the breach they just initiated
This isn’t a normal compromised server. Splunk is often the single highest-privilege observability system in an organization. The attacker sees your response to their own attack in real time. That’s the headline buried in the CVSS score.
Are You Affected?
Only self-managed Splunk Enterprise is affected. Splunk Cloud Platform is not affected — it doesn’t use the PostgreSQL sidecar architecture.
| Version Branch | Vulnerable Range | First Fixed Version |
|---|---|---|
| Splunk Enterprise 10.2.x | 10.2.0 – 10.2.3 | 10.2.4 |
| Splunk Enterprise 10.0.x | 10.0.0 – 10.0.6 | 10.0.7 |
| Splunk Enterprise 10.4.x | None | Safe from initial release |
| Splunk Enterprise 9.4 and below | Not affected | N/A |
The Timeline That Should Alarm You
The patch-to-exploitation window here was five days — from June 10 (disclosure and patch) to June 15 (confirmed active exploitation). Enterprise Splunk upgrades typically take two to four weeks to plan, test, and deploy. That gap is a problem, and it’s not unique to this CVE.
- June 10: Splunk releases patches and discloses CVE-2026-20253
- June 12: watchTowr publishes full RCE proof of concept
- June 15: Wild exploitation confirmed
- June 18: CISA adds to Known Exploited Vulnerabilities catalog
- June 21: Federal agency patch deadline — three days from CISA directive
CISA’s three-day deadline for federal agencies is one of the shortest patch windows ever issued for a non-zero-day vulnerability. That’s a signal about severity, not bureaucratic speed.
What to Do
Patch. Upgrade to Splunk Enterprise 10.2.4, 10.0.7, or 10.4.0. That’s the only complete fix. CISA’s guidance is unambiguous: patch immediately.
If you cannot patch right now, disable the PostgreSQL sidecar service by adding this to $SPLUNK_HOME/etc/system/local/server.conf and restarting Splunk:
[postgres]
disabled = trueBe aware: this breaks Edge Processor, OpAmp, and SPL2 data pipelines. It’s operationally painful, but it closes the attack surface while you schedule the upgrade.
To verify your exposure, watchTowr provides a detection check: send a request to the vulnerable endpoint. A 400 response (even with valid credentials in the Authorization header) means you’re vulnerable. A 401 means you’re patched or not affected.
Hunt for indicators of compromise. Look for unexpected files in /tmp/ or /opt/splunk/var/run/supervisor/pkg-run/, overwritten Python scripts in the splunk_secure_gateway app, and outbound PostgreSQL connections (port 5432) from your Splunk server to unknown external IPs. If you see those, assume you’re already breached and escalate.
The Broader Lesson
The PostgreSQL sidecar is a microservice added to enable new Splunk capabilities. Internal services accessed through a proxy aren’t “internal” — they’re reachable from anywhere the proxy is reachable. This pattern appears in plenty of other enterprise software: internal HTTP APIs, management sidecars, telemetry agents. If you’re running complex software, audit your “internal” service endpoints. The next CVE-2026-20253 is probably sitting in something you already trust.
