CVE-2026-20253: Splunk Enterprise CVSS 9.8 — Unauthenticated RCE Through a PostgreSQL Sidecar That Forgot to Lock Its Door

Sources: watchTowr Labs (primary) · Splunk Advisory SVD-2026-0603 · SecurityWeek · CybersecurityNews · Orca Security · GBHackers · Cyberpress · OffSeq | CVE: CVE-2026-20253 | CVSS: 9.8 Critical | CWE: CWE-306 | Published: June 10, 2026 | NOT affected: Splunk Cloud | Patched: 10.4.0, 10.2.4, 10.0.7, 9.4.12, 9.3.13

The tool watching your network for attackers just got an unauthenticated RCE

Splunk Enterprise is the SIEM backbone for thousands of enterprise security operations centers. It ingests logs from every system, fires detection alerts, stores forensic evidence, and is the primary visibility layer security analysts depend on to detect and respond to attacks. When Splunk is compromised, the attacker gains the security team’s eyes — every alert, every detection rule, every logged event, every investigation in progress. A compromised SIEM is the worst-case scenario for any security operations team, because the one tool you depend on to know you are under attack is now working for the attacker.

CVE-2026-20253 is a CVSS 9.8 Critical vulnerability in Splunk Enterprise that lets an unauthenticated attacker remotely execute arbitrary code on the Splunk server — no credentials, no session token, no prior access required. Published June 10, 2026 and researched in depth by watchTowr Labs, who published the full technical exploit chain and a detection tool. This is the third major security tool compromise DataWater has covered in 2026 — following the Trend Micro Apex One zero-day and the Palo Alto PAN-OS authentication bypass. The pattern is the same: the security tool becomes the attack surface.

The root cause: a sidecar that forgot to lock its door

Splunk Enterprise version 10 introduced the PostgreSQL Sidecar Service — an internal helper process managing PostgreSQL data storage. The sidecar exposes an HTTP API on port 5435, binding to localhost only. Under normal assumptions, a localhost-only service is inaccessible to remote attackers.

The problem: Splunk’s main web application on port 8000 includes a proxy mechanism that routes requests to internal services — including the PostgreSQL Sidecar. Any attacker who sends a request to port 8000 targeting /v1/postgres/recovery/backup or /v1/postgres/recovery/restore has it transparently proxied to the unauthenticated sidecar API. The sidecar assumes proxied requests are already authenticated by the main application. The main application never authenticates them. The attacker reaches an unauthenticated internal API through an externally accessible proxy. watchTowr Labs titled their research: “Why Use App-Level Auth When Every Database Has Auth?”

The exploit chain: from unauthenticated request to full RCE

Stage 1 — Reach the endpoint. HTTP request to Splunk port 8000 targeting the backup or restore path. No credentials. Proxy routes it to the sidecar which accepts it without authentication.

Stage 2 — Arbitrary file creation and truncation. The endpoints let the attacker control where PostgreSQL dumps filesystem contents. Files can be created or truncated anywhere the Splunk process has write access. Truncation disables critical databases. Creation is the RCE path.

Stage 3 — Database dump to controlled location. Attacker crafts a malicious PostgreSQL database containing attacker-controlled SQL, then instructs the endpoint to dump it onto the Splunk filesystem.

Stage 4 — Malicious SQL executes → RCE. The database is restored, malicious SQL runs, providing arbitrary file writes. From there: write a web shell, inject a cron job, write to a file Splunk’s server loads. Full RCE. watchTowr’s key finding: what Splunk’s advisory describes as “file truncation” is functionally equivalent to arbitrary code execution on the Splunk server. CVSS 9.8 is accurate — the advisory description undersells it.

AWS deployments: vulnerable out of the box

• Splunk Enterprise on AWS — PostgreSQL Sidecar installed and enabled by default. Every AWS-hosted Splunk Enterprise 10.x instance prior to patched builds is immediately vulnerable.
• Splunk Enterprise on-premise Linux — May be installed and enabled. Run watchTowr DAG to verify.
• Splunk Enterprise on-premise Windows — Sidecar not installed or enabled by default. Lower risk.
• Splunk Cloud — Not affected. No action required.

Organizations that migrated Splunk to AWS as part of cloud-first initiatives may not realize the migration introduced a new attack surface absent from their prior on-premise Windows deployment. A low-risk on-premise instance becomes a high-risk AWS instance because the cloud deployment enables the sidecar by default.

The companion vulnerabilities

CVE-2026-20251 (CVSS 8.8) — RCE via Splunk Secure Gateway through unsafe deserialization of KV Store data using the jsonpickle Python library. Low-privileged user achieves RCE. Same patch closes both.

CVE-2026-20252 (CVSS 7.6) — SSRF via Dashboard Studio PDF export. Bypasses trusted-domain validation through prefix matching and redirect following. Low-privileged users can reach internal network destinations including cloud metadata services.

CVE-2026-20254 (CVSS 6.1) — Stored XSS via classic dashboard HTML panels. Malicious JavaScript executes in analysts’ browsers during active investigations — session token theft and analyst workstation compromise are realistic outcomes in a SOC context.

Why a compromised SIEM is the worst-case scenario

An attacker with RCE on Splunk gains: every security log from every system, every active detection rule and alert configuration, every ongoing incident investigation, credentials and API tokens in Splunk configurations, and months of historical log data revealing monitoring gaps. They can disable specific detection rules covering their subsequent activity, delete log evidence of their presence, inject false data to confuse investigations, monitor the security team’s response in real time, and pivot laterally using Splunk’s privileged network position.

The Verizon DBIR 2026 found exploitation of internet-facing applications is the #1 breach initial access vector. Your SIEM is an internet-facing application. CVE-2026-20253 in Splunk, CVE-2026-20245 in Cisco SD-WAN, and CVE-2026-34926 in Trend Micro Apex One are three separate 2026 confirmations that attackers are systematically targeting security infrastructure specifically because compromising it yields disproportionate access.

Detection: test your instance right now

# watchTowr Detection Artifact Generator
git clone https://github.com/watchtowrlabs/CVE-2026-20253-dag
cd CVE-2026-20253-dag
python3 dag.py --target https://your-splunk-instance:8000
# HTTP 400 = VULNERABLE — patch immediately
# HTTP 401 = patched or protected

# Manual: verify sidecar is running
ss -tupln | grep -i splunk-postgres
# Any results = sidecar is active

# Manual: check Splunk version
/opt/splunk/bin/splunk version
# Patched versions: 10.4.0, 10.2.4, 10.0.7, 9.4.12, 9.3.13

# Splunk search: look for requests to vulnerable endpoints in access logs
index=_internal sourcetype=splunk_web_access
  (uri_path="/v1/postgres/recovery/backup" OR uri_path="/v1/postgres/recovery/restore")
| table _time, clientip, uri_path, status
| sort -_time

# Check for unexpected files in sidecar directory
find /opt/splunk/var/run/supervisor/pkg-run/ -newer /opt/splunk/bin/splunk -ls 2>/dev/null

Remediation steps

1. Patch immediately — upgrade to 10.4.0, 10.2.4, 10.0.7, 9.4.12, or 9.3.13. Closes CVE-2026-20253 and CVE-2026-20251 simultaneously.
2. If you cannot patch — block external access to port 8000 from untrusted networks. Route analyst access through VPN or jump host.
3. If you cannot block port 8000 — stop and disable the splunk-postgres sidecar service. Review feature dependencies before disabling.
4. Run watchTowr DAG against all Splunk instances. HTTP 400 = still vulnerable. HTTP 401 = protected.
5. Audit the filesystem — check /opt/splunk/var/run/supervisor/pkg-run/ for unexpected files. Search historical access logs for requests to the vulnerable endpoints.
6. Rotate all credentials stored in Splunk configurations if exploitation indicators are found.
7. Restore detection rules from backup if exploitation indicators are found — an attacker with SIEM access may have modified or deleted rules to cover their activity.
8. Verify CVE-2026-20251 is closed — if your organization runs Splunk Secure Gateway, confirm the jsonpickle RCE path is patched simultaneously.

Sources and further reading

• watchTowr Labs — Full CVE-2026-20253 Technical Breakdown (Primary Research)
• Splunk — Official Advisory SVD-2026-0603
• SecurityWeek — Splunk, Palo Alto Networks Patch Severe Vulnerabilities
• CybersecurityNews — Splunk Enterprise Pre-Auth RCE Chain
• Orca Security — CVE-2026-20253: Splunk Enterprise RCE and File Operation Flaws
• GBHackers — Critical Splunk Enterprise Pre-Auth RCE Chain
• Cyberpress — Critical Splunk Enterprise Flaw Enables Unauthenticated RCE

DataWater — Article #28 — June 14, 2026. Previous: CVE-2026-35273 Oracle PeopleSoft (June 12) · $1,000 AI Agent FFmpeg Zero-Days (June 10) · Microsoft Patch Tuesday (June 10). Full archive →