CVE-2026-20253: CISA Warns of Actively Exploited Splunk Enterprise RCE

Splunk Enterprise admins should prioritize patching CVE-2026-20253, a critical vulnerability that allows a network-reachable, unauthenticated attacker to create or truncate arbitrary files on the Splunk server. Under certain conditions, this can be chained into remote code execution (RCE), making exposure the main risk driver. CISA has added this to its Known Exploited Vulnerabilities catalog, confirming active exploitation in the wild.

This post covers what’s affected, how the attack works at a high level, what we know about exploitation, and what defenders should do now.

What Is CVE-2026-20253?

CVE-2026-20253 (CVSS 9.8) is a missing authentication flaw (CWE-306) in Splunk Enterprise. An attacker who can reach the vulnerable service over the network can trigger file operations without logging in.

The direct, confirmed impact is arbitrary file creation or file truncation on the Splunk Enterprise host. Even without a built-in “execute command” step, unauthenticated file write or destruction can enable outcomes like service disruption, persistence, or a later execution path depending on how the target is configured.

Which Splunk Enterprise Versions Are Affected?

According to the official Splunk security advisory, affected Splunk Enterprise versions include:

• 10.0.0 to 10.0.6 (fixed in 10.0.7)
• 10.2.0 to 10.2.3 (fixed in 10.2.4)

From a risk standpoint, the highest-priority cases are Splunk Enterprise systems where management or related service endpoints are reachable from untrusted networks, including internet-facing deployments or internal networks with weak segmentation.

What Component Is Vulnerable, and Why Does It Matter?

The vulnerable component is Splunk Enterprise’s PostgreSQL sidecar service endpoint. The endpoint performs file creation or truncation actions without enforcing authentication.

That matters because it turns network access into filesystem impact. If an attacker can write or truncate files on a Splunk server, they may be able to:

• Corrupt configuration or operational files to cause availability impacts
• Plant files that later get interpreted by another process (a common stepping stone toward code execution)
• Set up follow-on actions that make incident response harder (for example, damaging logs or changing runtime behavior)

Splunk servers also tend to sit in high-trust parts of the environment and may hold sensitive data or credentials, which increases the blast radius if compromise occurs.

How Could CVE-2026-20253 Be Exploited in Practice?

At a high level, exploitation starts with a remote attacker reaching the sidecar endpoint and invoking unauthenticated file operations to create or truncate files on disk.

watchTowr Labs published a technical write-up and proof-of-concept (PoC) exploit code on June 12, confirming that the file-write primitive chains into RCE. The technique abuses PostgreSQL features such as lo_export to write scripts and then execute them.

The practical takeaway is that this is not just a “file nuisance” bug; a working exploit chain is public, and pre-auth file write can become a full compromise if attackers place files in locations that influence execution.

Is There Active Exploitation?

Yes, active exploitation is confirmed.

On June 18, Splunk updated its advisory to acknowledge limited in-the-wild exploitation, and CISA added CVE-2026-20253 to its Known Exploited Vulnerabilities catalog the same day. Notably, CVE-2026-20253 is the first Splunk vulnerability ever added to the KEV list.

Federal Civilian Executive Branch (FCEB) agencies are required to remediate by June 21, 2026. The gap from public PoC (June 12) to confirmed exploitation (June 18) was under a week.

As organizations work to reduce risk from newly disclosed vulnerabilities, SOCRadar Cyber Threat Intelligence helps security teams track exploit developments, patch-related updates, and broader threat activity around high-impact flaws. Combined with Attack Surface Management (ASM), it also helps identify exposed assets that may require faster action, supporting more informed remediation and prioritization.

What Should Defenders Do Now?

Apply fixes where possible

The most direct remediation is to upgrade Splunk Enterprise to a fixed version:

• 10.0.7 or later (10.0 branch)
• 10.2.4 or later (10.2 branch)

Given the severity, pre-auth nature, and confirmed active exploitation with public PoC code, this is a strong candidate for an emergency change window rather than a standard patch cycle.

Use the recommended workaround if patching is blocked

If you cannot upgrade immediately, the mitigation explicitly called out by the vendor is to disable the PostgreSQL sidecar service. This reduces the attack surface by removing the vulnerable endpoint entirely, but it may have operational impacts depending on how your deployment uses the sidecar.

Reduce exposure aggressively

Even with patching planned, reduce reachability:

• Ensure Splunk management and related service endpoints are not internet-exposed
• Restrict access to required admin networks only
• Validate segmentation between user subnets and Splunk infrastructure networks

Exposure is the difference between “theoretical risk” and “remote compromise path.”

Add detection focused on file operations and Splunk child processes

For near-term monitoring and hunting, prioritize signals that align to the vulnerability’s behavior:

• Review edge telemetry (reverse proxy, WAF, firewall) for unusual POST activity directed at Splunk sidecar-related services
• Monitor for unexpected filesystem modifications on Splunk hosts, especially sudden truncation or creation of files in sensitive directories
• Watch EDR telemetry for anomalous child processes spawned by Splunk services that do not match normal administrative workflows

IPS or network signatures can help as defense-in-depth, but they should not replace patching or service disablement for a pre-auth critical issue with a public exploit chain.