Splunk CVE-2026-20253: a Pre-Auth RCE Inside Your SIEM

The tool you bought to watch everything else just became the thing that needs watching. On 10 June 2026 Splunk published SVD-2026-0603, disclosing CVE-2026-20253 — an unauthenticated, network-reachable flaw in Splunk Enterprise that lets an attacker create or truncate arbitrary files on the host, with a clean path from there to remote code execution. CVSS 9.8. No credentials. By the weekend of 13–14 June the technical write-ups were public, including a full exploit chain. Splunk is, for a large share of enterprises and SOCs, the system of record for detection — the place security events go to be believed. A pre-auth RCE in that system is not just another edge-appliance CVE. It is a hole in the thing you trust to find holes.

What CVE-2026-20253 actually is

Splunk 10 introduced a PostgreSQL "sidecar" — a splunk-postgres service bound to localhost:5435 that the platform uses for internal recovery and backup operations. The main web application on port 8000 can proxy requests through to it via a __raw path: /en-US/splunkd/__raw/v1/postgres/recovery/. Two endpoints under that path — /backup and /restore — were shipped without authentication controls. Any value in the Authorization header is accepted and never validated. Per Splunk's own advisory, the result is that "an unauthenticated user could create or truncate arbitrary files through a PostgreSQL sidecar service endpoint."

The affected and fixed builds, straight from the advisory:

Branch	Affected	Fixed in
Splunk Enterprise 10.2	10.2.0 – 10.2.3	10.2.4
Splunk Enterprise 10.0	10.0.0 – 10.0.6	10.0.7
Splunk Enterprise 10.4	not affected	10.4.0

One detail decides how exposed you are: the sidecar is not installed by default on manual on-prem installs, but it is enabled by default on Splunk Enterprise running on AWS. Splunk Cloud (the managed SaaS) does not use the sidecar and is not affected. So the worst-exposed population is self-managed Splunk Enterprise on AWS — exactly the deployment a lot of teams reach for when they want SIEM control without running the metal themselves.

From an unauthenticated request to code execution

A file-write primitive is not automatically RCE. The interesting part of watchTowr Labs' analysis is how the two recovery endpoints compose into one. The /backup endpoint shells out to pg_dump with attacker-influenced parameters; the database argument flows through to a PostgreSQL connection string, and a hostaddr in that string overrides the hardcoded -h localhost. That means the "backup" can be pointed at a database the attacker controls. The /restore endpoint then runs pg_restore, which replays SQL and executes PL/pgSQL embedded in the dump.

Chained, it looks like this:

• Stand up an attacker-controlled PostgreSQL instance containing a malicious function that calls lo_export to write a chosen byte payload to a chosen path.
• Call /backup to pull that database into a file on the Splunk filesystem.
• Call /restore to replay it; during restore, lo_export fires and writes the payload to disk on the Splunk host.
• Aim the write at a Python script Splunk runs on its own schedule. In the public PoC, the target was /opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py. Splunk executes it routinely — and now it runs the attacker's code, as the splunk user.

There is a quieter variant. Because the connection string is attacker-controllable, the same endpoint can be steered to internal hosts the Splunk box can reach but the attacker can't — a server-side request forgery pivot into the network, which Orca Security's write-up flags alongside the file-operation and RCE impact. A SIEM is, by design, a machine that everything else talks to. Owning it hands an attacker a privileged vantage point onto the rest of the estate.

"We patched Splunk last quarter." — "Which Splunk? The forwarders, the indexers, or the AWS-hosted search head someone spun up for a migration in March and never folded into the patch SLA?"

That second question is where most of these incidents actually live.

Why a bug in Splunk is worse than a bug in almost anything else

There is a category error built into how most organisations reason about security products. A vulnerable VPN or a vulnerable ERP is understood as a risk. A vulnerable security tool tends to get a pass, because it sits in the mental column marked "the thing that protects us," not the column marked "asset that can be attacked." That instinct is wrong, and the last few months have made it expensively obvious — security and management products keep landing on CISA's Known Exploited Vulnerabilities catalog, and we wrote in May about endpoint-protection zero-days being added to KEV for the same structural reason.

The reason it is worse, not merely equal, comes down to three properties a SIEM uniquely holds:

• Reach. Every other system forwards logs to it, so it has network paths to nearly everything. That is precisely what the SSRF angle of CVE-2026-20253 monetises.
• Trust. Analysts treat what the SIEM says as ground truth. An attacker with code execution there can suppress, alter, or fabricate the very telemetry your detection logic depends on.
• Credential gravity. A SIEM accumulates service accounts, API tokens, and integration secrets so it can pull data from everywhere. The PoC even reads .pgpass off disk to authenticate the restore step; that is a small sample of the secret material these boxes hoard.

The blind spot: a SIEM cannot witness its own compromise

Here is the failure mode that should keep defenders up at night. If the platform that ingests and correlates your detection telemetry is the platform being exploited, your detection telemetry is exactly the wrong place to look for the attack. Code execution as the splunk user is code execution inside the witness. The first thing competent operators do after landing in a log pipeline is stop it from logging them.

So the question stops being "will my SIEM alert on this?" and becomes "what observes the SIEM?" There is one answer that does not depend on the SIEM's integrity: the wire. The unauthenticated POSTs to /en-US/splunkd/__raw/v1/postgres/recovery/, the outbound connection from the Splunk host to an attacker-controlled PostgreSQL instance, the SSRF probes fanning into internal ranges, the new periodic process beaconing out — all of it is traffic, and traffic is observable independently of whether the endpoint generating it is still trustworthy. An attacker can blind a log source. Blinding the network they are moving across is much harder, and they usually do not bother trying.

What "just patch it" quietly skips

Patching Splunk to 10.2.4 / 10.0.7 / 10.4.0 is necessary and you should do it today. But "patch the CVE" is an answer to a question nobody asked precisely. The operational questions CVE-2026-20253 actually raises are:

• Do you know every Splunk Enterprise instance you run, including the shadow search head on AWS that a team stood up for a one-off migration and never inventoried?
• For each instance, is the PostgreSQL sidecar present and reachable — i.e. are you actually exposed, or just nominally on a vulnerable version?
• If one of these boxes had been popped two weeks before the advisory, would anything other than the box itself have noticed?

An annual or quarterly penetration test answers none of these for a CVE that was published four days ago. The model that does is continuous, and it has to treat the security stack as an asset to be attacked — not as a trusted observer exempt from testing.

Where Zero Hunt fits the scenario

This is the gap Zero Hunt is built to close, and CVE-2026-20253 lines up with it almost too neatly. The platform's 10-agent AI swarm — Recon, Exploit, Web, Credential, Post-Exploit, Pivot, Tactic and Report, under an AI Controller — runs continuously against your own estate, including the boxes you think of as defensive. The Recon agent finds the uninventoried AWS search head; the Web and Exploit agents probe whether the /v1/postgres/recovery/ path actually answers without auth on that host, rather than assuming from a version banner. Exploits are generative: written per-target by a local LLM, not pulled from a public PoC, so the validation reflects your configuration — sidecar present or not, reachable or not — instead of a generic yes/no. Every new offensive skill is backtested in the AI Gym against corpora like Vulhub and the CVE-based black-box tasks before it is ever allowed near production, and each confirmed finding is ECDSA-signed with chain-of-custody so "we tested the SIEM and here is exactly what was reachable on which date" is a defensible record, not a memory.

The second half of the problem — the witness that survives the SIEM being the victim — is the AI Traffic Analysis model. It is a proprietary deep-learning engine with four parallel inference heads (suspicious traffic, malware classification, attack-type identification, application fingerprinting), trained on billions of PCAP sequences, running locally on the appliance GPU at 2.7+ Gbit/s. It does not ask Splunk what happened. It watches the unauthenticated recovery POSTs, the outbound database connection to a never-seen ASN, and the SSRF fan-out as they cross the wire — independent of whether the host generating them is still honestly reporting. When the thing being attacked is the thing you'd normally trust to tell you, an observer that owes it nothing is the difference between catching the intrusion and reading about it in next quarter's advisory.

Sources: Splunk advisory SVD-2026-0603 (10 June 2026); watchTowr Labs technical analysis; Orca Security; CISA KEV catalog.