By ByteBot
Your SIEM is supposed to detect attacks. CVE-2026-20253 means it can now be the attack. This is a CVSS 9.8 pre-authentication remote code execution vulnerability in Splunk Enterprise — no credentials required, network access is enough, and working exploit code has been public since June 12. CISA added it to the Known Exploited Vulnerabilities catalog on June 18 and gave federal agencies until June 21 to patch. That deadline passed. Private sector organizations are still catching up.
What the Vulnerability Is
Splunk Enterprise versions 10.0 and 10.2 ship with a PostgreSQL sidecar service — an internal process handling Edge Processor, OpAmp, and SPL2 data pipelines. This service exposes two REST endpoints on Splunk’s management port (8089):
POST /splunkd/__raw/v1/postgres/recovery/backupPOST /splunkd/__raw/v1/postgres/recovery/restore
Neither endpoint requires authentication. Any network-reachable attacker can call them freely. The root cause is CWE-306 — Missing Authentication for Critical Function — the kind of bug that makes security engineers wince, because it’s not subtle. The PostgreSQL sidecar service was built assuming network isolation would keep attackers out. That assumption did not hold.
Are You Affected?
Splunk Enterprise 10.2.0 through 10.2.3 and 10.0.0 through 10.0.6 are vulnerable. Fixed versions are 10.2.4, 10.0.7, and 10.4.0+. Version 9.x is not affected. Splunk Cloud is not affected — Splunk patched it automatically. If you’re running on-premise Splunk Enterprise in either of those branches, assume you are exposed until you verify your version. Check the official Splunk advisory SVD-2026-0603 for the complete version matrix.
How Attackers Chain File Write Into RCE
WatchTowr published the technical breakdown and a working proof-of-concept on June 12. The chain runs like this: an attacker calls the /backup endpoint, pointing pg_dump at an attacker-controlled PostgreSQL server. That malicious database contains lo_export() function calls that write arbitrary content to predictable paths on the Splunk filesystem. The attacker then calls /restore — pg_restore executes and runs those embedded functions, dropping attacker-controlled Python files into Splunk app directories. Splunk executes those scripts as its service account, which is frequently root or another high-privilege user. No credentials involved at any step.
Active exploitation began June 15 — three days after WatchTowr’s write-up dropped. CISA confirmed limited exploitation activity that same week.
Why a Compromised SIEM Is Worse Than Most Breaches
Splunk isn’t just another server. It’s the system ingesting logs from your firewalls, endpoints, cloud workloads, and identity providers. An attacker with RCE on your Splunk instance can read or delete all security logs, modify detection rules and alert thresholds to suppress visibility, and see exactly what your team can and cannot detect. They can quietly cover their tracks across every other system in your environment. Compromising the SIEM is often step zero for ransomware operators who want to move undetected — and now there’s a pre-auth exploit to do it with.
Fix It: Three Options, One Clear Winner
Option 1 (recommended): Upgrade now. Patch to Splunk Enterprise 10.2.4, 10.0.7, or 10.4.0+. This is the only complete fix. Splunk released patched versions on June 10 — this should have happened two weeks ago.
Option 2 (interim only): Disable the PostgreSQL sidecar service. Add the following to $SPLUNK_HOME/etc/system/local/server.conf and restart Splunk:
[postgres]
disabled = trueThis eliminates the vulnerable surface, but it breaks Edge Processor, OpAmp, and SPL2 data pipelines. Only use this if you genuinely cannot patch immediately.
Option 3 (not a fix): Restrict port 8089. Locking the management port to authorized hosts via firewall rules reduces exposure but does not fix the vulnerability. Treat this as hardening, not remediation.
Detect Exploitation Attempts
Run this SPL query against your internal Splunk logs to catch any access to the vulnerable endpoints:
index=_internal source="*/splunkd.log"
( uri="/splunkd/__raw/v1/postgres/recovery/backup"
OR uri="/splunkd/__raw/v1/postgres/recovery/restore" )
| stats count by src_ip, uri, method, statusAlso check for unexpected Python files recently modified in your Splunk app directories:
find /opt/splunk/etc/apps -newer /opt/splunk/etc/.build -name "*.py" -type fAny results from either query warrant immediate investigation. If you find evidence of compromise, assume log integrity is already at risk — cross-reference with other log sources before trusting Splunk output.
Bottom Line
WatchTowr named their post “Why Use App-Level Auth When Every Database Has Auth?” — a pointed way of describing how an internal service that assumed isolation instead of enforcing authentication ended up as a CVSS 9.8 exploit. Splunk patched this on June 10. The PoC dropped June 12. Attackers moved on June 15. Check your version now, and if you’re on any 10.0 or 10.2 release before the fix, stop reading and go patch.
