The SIEM that never asked for a password

The origin

CVE-2026-20253. CVSS 3.1: 9.8 CRITICAL, vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. CWE-306: Missing Authentication for Critical Function. Assigning CNA: Cisco, which has owned Splunk since 2024.

Decoded: reachable from the network, low complexity, no privileges required, no user interaction, total loss of confidentiality, integrity and availability. It is the worst profile a CVE can carry.

The timeline is tight:

• 10 June 2026 — Splunk publishes advisory SVD-2026-0603
• 12 June — watchTowr Labs publishes full technical analysis with PoC
• 18 June — Splunk confirms "limited exploitation" in the wild. The same day, CISA adds it to the KEV catalog with a remediation deadline of 21 June (BOD 26-04)

Three days to patch, for US federal agencies. Shadowserver counted more than 1,400 Splunk instances exposed to the internet at the time — 952 in North America, 223 in Europe. How many were actually vulnerable is unknown.

Affected: Splunk Enterprise 10.2.0–10.2.3 and 10.0.0–10.0.6. Splunk Cloud Platform is not affected.

The attack chain

The culprit is the PostgreSQL Sidecar Service, an internal component Splunk uses for its own data pipelines. It should only ever talk to itself over loopback. It didn't work out that way.

The chain reconstructed by watchTowr — described here conceptually, without reusable code — is a sequence of four misplaced trusts:

1. 01
   Reverse proxy

   the web server on port 8000 exposes the sidecar's internal endpoints
2. 02
   Authorization header

   any value is accepted, never validated
3. 03
   database parameter

   takes a connection string that overrides the host
4. 04
   passfile option

   Splunk reads its own .pgpass and hands over admin credentials
5. 05
   /restore

   a malicious dump becomes arbitrary file write, then RCE

First trust: the reverse proxy. Splunk's main web server (port 8000, listening on all interfaces) exposes internal sidecar endpoints — /v1/postgres/recovery/backup and /restore — that were meant for loopback only. And authentication? Any value in the Authorization header is accepted. Not validated. Accepted.

Second trust: the database parameter. It should hold a database name. It instead accepts an entire PostgreSQL connection string, which overrides hardcoded parameters — including the host. So an attacker can persuade Splunk to connect to a PostgreSQL database they control.

Third trust: the passfile option. Abusing it, you can make Splunk read its own local .pgpass file — handing over the credentials of the internal administrative PostgreSQL user.

Fourth trust: /restore. With those credentials, a malicious dump gets restored onto the local instance, yielding an arbitrary file write primitive.

From there to RCE is short: overwrite a Python script Splunk runs periodically — ssg_enable_modular_input.py — and wait.

None of these four steps is a memory corruption exploit. They are four design decisions that, individually, looked reasonable.

Detection

Splunk's advisory states, verbatim, "Detections: None". No official IOCs: no hashes, no IPs, no domains. You're on your own.

What you can still hunt for:

• HTTP requests to /en-US/splunkd/__raw/v1/postgres/recovery/backup or /restore — these should never arrive from outside
• Unexpected files in /opt/splunk/var/run/supervisor/pkg-run/pkg-postgres*/
• Unplanned modifications to ssg_enable_modular_input.py — that one means you're already past the point of prevention
• Outbound PostgreSQL connections from the sidecar to external hosts. An internal database has no business calling the internet

watchTowr published a public check script that distinguishes vulnerable instances by the backup endpoint's HTTP response (400 vs 401).

Remediation

Patch: upgrade to Splunk Enterprise 10.4.0, 10.2.4 or 10.0.7 (or later). There is no elegant alternative.

Temporary mitigation, if you truly cannot patch now: disable the sidecar with [postgres] disabled = true in server.conf.

But note — and this is the part the advisory says and many skip: this mitigation breaks Edge Processor, OpAmp and SPL2 data pipelines. It is not a free switch. It breaks functionality you are probably using.

A note on sources: on NVD the 9.8 score is listed "as provided by CNA" — independent NVD enrichment had not yet completed. And Splunk confirms exploitation without detailing what the observed attackers were after.

What it teaches

The irony writes itself: a critical pre-auth vulnerability in a SIEM. The tool organisations buy precisely to notice intrusions, undone by a database component that trusts anyone who knocks. watchTowr's researchers put it better than we could: Splunk decided authentication is somebody else's problem.

But there are two less obvious lessons.

The first is about defaults. The sidecar ships enabled by default on Splunk Enterprise on AWS: anyone with that deployment was vulnerable out of the box, having configured nothing wrong. Manual on-prem Windows installs often have it disabled. Same CVE, same CVSS, radically different real-world risk depending on how you installed the product. The score doesn't tell you that.

The second is about who found the bug. watchTowr used an internal LLM agent — "Project Red" — to suggest the HTTP request that turned out to be the linchpin of the whole chain. That's AI-assisted vulnerability research, applied successfully to a security product, documented publicly. Worth noting: the craft this site covers is changing its own tools.