Zerodayhub

Splunk Enterprise Pre-Auth RCE – CVE-2026-20253

TL;DR: A missing-authentication flaw in Splunk Enterprise lets an unauthenticated attacker on the network create or overwrite files on the Splunk server — and a public exploit chains that into full remote code execution. It is already being exploited in the wild, it is on CISA’s KEV list, and you should upgrade to a fixed build today.

Key takeaways

• CVE-2026-20253 is a CVSS 9.8 critical vulnerability in Splunk Enterprise’s PostgreSQL sidecar service, caused by a completely missing authentication check (CWE-306).
• An unauthenticated, network-reachable attacker can create or truncate arbitrary files on the host; watchTowr Labs’ public proof-of-concept escalates this to pre-authentication remote code execution.
• It is actively exploited — Splunk confirmed limited in-the-wild abuse and CISA added it to the Known Exploited Vulnerabilities catalogue on 18 June 2026, the first Splunk flaw ever to make the list.
• Fixed in Splunk Enterprise 10.0.7 and 10.2.4 (and later releases). If you cannot patch immediately, disable the PostgreSQL sidecar service and pull the management interface off untrusted networks.

What is CVE-2026-20253?

CVE-2026-20253 is a critical, maximum-impact vulnerability in Splunk Enterprise — the security information and event management (SIEM) platform that sits at the heart of countless corporate detection and monitoring stacks. The flaw lives in Splunk’s PostgreSQL “sidecar” service, a helper component bundled with the platform. That service exposes a file-operation endpoint that performs no authentication whatsoever, so any attacker who can reach it over the network can invoke privileged file operations without ever logging in.

The irony is hard to miss: the system organisations rely on to catch intrusions can itself be turned into the intrusion. Splunk disclosed the issue on 10 June 2026 in advisory SVD-2026-0603, scoring it 9.8 on the CVSS v3.1 scale and classifying it as CWE-306, “Missing Authentication for Critical Function”. Within days a working exploit chain was public and attacks were under way.

How the Splunk sidecar exploit works

In plain terms: a component that should have demanded a password demands nothing. An attacker simply sends a request to the vulnerable endpoint and the server carries out file actions on their behalf — as if they were a trusted local process.

In more technical detail, the root cause is an authentication gap in the PostgreSQL sidecar service endpoint. The direct, confirmed primitive is arbitrary file creation and file truncation on the Splunk host. On its own that already enables denial of service (corrupting or zeroing configuration and operational files) and tampering (damaging the very logs a defender would reach for during incident response).

The serious escalation comes from chaining. On 12 June 2026, watchTowr Labs published a technical write-up and proof-of-concept showing how the file-write primitive becomes full pre-authentication remote code execution. The technique abuses native PostgreSQL functionality — large-object export routines such as lo_export — to write attacker-controlled script content to a location on disk and then have it executed, converting “I can write a file” into “I can run commands”. Because the attack needs no credentials and no user interaction, and Splunk servers frequently hold privileged data and credentials, the blast radius is large.

The pre-conditions are minimal: network reachability to the affected service on an unpatched 10.0 or 10.2 build. Internet-facing deployments and flat internal networks with weak segmentation are the highest-risk cases. The snippet below is a non-operational, illustrative sketch of the request-then-chain pattern — it deliberately omits the working payload:

# ILLUSTRATIVE ONLY — not a working exploit
POST /<sidecar-file-endpoint> HTTP/1.1
Host: splunk.victim.example:<port>
Content-Type: application/json
{ "operation": "write", "path": "<server-writable-path>", "data": "<redacted>" }
# Observed real-world chain (conceptual):
#   1. Unauthenticated file write/truncate via sidecar endpoint
#   2. Abuse PostgreSQL large-object export (e.g. lo_export) to drop a script
#   3. Trigger execution -> remote code execution as the Splunk service account

Is CVE-2026-20253 actively exploited?

Yes. This is not a theoretical risk. On 18 June 2026 Splunk updated its advisory to acknowledge limited exploitation in the wild, and on the same day CISA added CVE-2026-20253 to its Known Exploited Vulnerabilities (KEV) catalogue — notably the first Splunk vulnerability ever to appear on that list. CISA set a Federal Civilian Executive Branch remediation deadline of 21 June 2026, which for a non-federal reader is best understood as “this should already have been fixed”.

The exploitation window was brutally short. Public proof-of-concept code landed on 12 June, and confirmed in-the-wild abuse followed within six days — a textbook example of how quickly a pre-auth flaw with a published chain gets weaponised. As of publication, exploitation has been described as “limited”, but with mass-deployed software, a public PoC and KEV listing, opportunistic scanning and follow-on attacks should be assumed.

How to fix CVE-2026-20253: remediation & mitigation

Patch: Upgrade Splunk Enterprise to a fixed release — 10.0.7 or later on the 10.0 branch, and 10.2.4 or later on the 10.2 branch (later major releases also contain the fix). Given the pre-auth nature, the public exploit and confirmed exploitation, this warrants an emergency change window rather than the next routine patch cycle.

If you can’t patch immediately:

• Disable the PostgreSQL sidecar service — the vendor-recommended workaround, which removes the vulnerable endpoint entirely. Validate the operational impact for your deployment first, as some configurations depend on it.
• Take Splunk management and related service endpoints off the public internet and restrict access to dedicated administrative networks only.
• Tighten network segmentation between user subnets and Splunk infrastructure so the service simply cannot be reached by untrusted hosts.

After patching: Treat any exposed, unpatched server as potentially compromised. Hunt for unexpected file creation or truncation on Splunk hosts, review the integrity of configuration and log files, rotate credentials and secrets held on or accessible from the server, and terminate sessions of concern. Because the bug allows log tampering, do not treat clean local logs as proof of safety — corroborate with upstream telemetry.

Detection / IOCs: Review edge telemetry (reverse proxy, WAF, firewall) for unusual POST activity aimed at Splunk sidecar-related services; monitor for sudden, unexplained file truncation or creation in sensitive directories on Splunk hosts; and watch EDR for anomalous child processes spawned by Splunk services that fall outside normal administrative workflows. Network IPS signatures are useful defence-in-depth but are not a substitute for patching or disabling the sidecar.

Frequently asked questions

Is Splunk Cloud affected, or only on-premises Splunk Enterprise?

The confirmed affected product is on-premises Splunk Enterprise on the 10.0 and 10.2 branches. Cloud-platform exposure was not separately confirmed in the sources reviewed for this article; Splunk-managed cloud environments are typically remediated by the vendor. Check advisory SVD-2026-0603 for the authoritative product scope.

Can the attacker run commands, or just write files?

Both, in practice. The directly confirmed flaw is unauthenticated file create/truncate, but watchTowr Labs’ public PoC chains it into remote code execution via PostgreSQL large-object export functionality. Assume RCE is achievable on an exposed, unpatched host.

We’re behind a firewall — are we safe?

Lower risk, not zero. The flaw needs network reachability to the sidecar service, so internet-facing servers are the priority. But flat internal networks, weak segmentation or a foothold elsewhere can still expose the endpoint to an attacker. Patch regardless.

How urgent is this really?

Very. CVSS 9.8, no authentication, a public exploit chain, KEV listing and confirmed in-the-wild exploitation within a week of the PoC — this is an emergency-patch-class issue.

Sources & further reading

• Splunk security advisory SVD-2026-0603 — advisory.splunk.com/advisories/SVD-2026-0603
• CISA, “CISA Adds One Known Exploited Vulnerability to Catalog” (18 June 2026) — cisa.gov
• NVD entry, CVE-2026-20253 — nvd.nist.gov/vuln/detail/CVE-2026-20253
• watchTowr Labs, technical write-up & PoC — labs.watchtowr.com
• SOCRadar, “CVE-2026-20253: CISA Warns of Actively Exploited Splunk Enterprise RCE” — socradar.io
• NetSPI, “Splunk Enterprise Unauthenticated Arbitrary File Operations/RCE (CVE-2026-20253)” — netspi.com

ZeroDayHub tracks critical vulnerabilities as they break. Subscribe for updates.