CISA Gives Agencies Three Days to Patch Exploited Splunk Enterprise Flaw

CISA has added an actively exploited Splunk Enterprise flaw to its Known Exploited Vulnerabilities catalog, giving federal agencies until June 21 to address CVE-2026-20253 on exposed assets.

SecurityWeek reported the exploitation warning on June 19, 2026, after both CISA and Splunk updated public guidance on June 18. The bug is not a speculative hardening issue: CISA says it added CVE-2026-20253 to the KEV catalog based on evidence of active exploitation, and Splunk says its Product Security Incident Response Team became aware of limited exploitation in June.

For security teams, the short version is simple. If Splunk Enterprise 10.0 or 10.2 is running in a place an attacker can reach, this is a patch-now item rather than a normal maintenance-window item.

What changed on June 18

CISA’s alert identifies the issue as “Splunk Enterprise Missing Authentication for Critical Function Vulnerability” and says this class of bug is a frequent attack vector for malicious cyber actors. The agency’s KEV catalog feed lists June 18, 2026 as the date added and June 21, 2026 as the due date for federal remediation under Binding Operational Directive 26-04.

The directive applies to Federal Civilian Executive Branch agencies, but the operational signal is broader. KEV entries are often the point where patch planning should shift from “the vendor shipped an advisory” to “assume defenders and attackers are both racing.”

The affected Splunk Enterprise versions

Splunk’s SVD-2026-0603 advisory describes CVE-2026-20253 as an unauthenticated arbitrary file creation and truncation issue in a PostgreSQL sidecar service endpoint. Splunk gives it a CVSS 9.8 critical rating and maps it to CWE-306, missing authentication for a critical function.

Patch levels named by Splunk

According to Splunk, the affected product lines are:

• Splunk Enterprise 10.2.0 through 10.2.3, fixed in 10.2.4.
• Splunk Enterprise 10.0.0 through 10.0.6, fixed in 10.0.7.
• Splunk Enterprise 10.4 is listed as not affected, with 10.4.0 named as a fixed release.
• Splunk Enterprise 9.4 and earlier are listed by Splunk as not affected.

Splunk says the vulnerable PostgreSQL sidecar endpoint lacks authentication controls, allowing a network-reachable user to invoke file operations without credentials. That wording matters: exposure and network reachability can decide whether the issue is an internal cleanup task or an emergency incident-response trigger.

Why defenders should treat this as urgent

Public research raised the exploitability stakes

SecurityWeek notes that watchTowr researchers published technical details two days after Splunk’s June 10 advisory and demonstrated how the file-write primitive could be taken toward pre-authentication remote code execution. Splunk’s own advisory does not need to describe every attacker path for the risk to be real: CISA’s KEV action and Splunk’s limited-exploitation statement are enough to prioritize remediation.

The incident is also a reminder that observability and security platforms deserve stricter exposure reviews than ordinary internal applications. A compromised logging platform can become a pivot point, a data source for attackers, or a way to interfere with detection evidence during an investigation.

What operators should do now

Upgrade first where possible

Splunk’s primary recommendation is to upgrade to 10.4.0, 10.2.4, 10.0.7, or higher. Teams should inventory Splunk Enterprise versions across production, disaster recovery, lab, and forgotten departmental deployments, then prioritize any instance whose management or sidecar endpoints are reachable from untrusted networks.

Use the workaround only with product-impact review

For Splunk Enterprise 10.0 and 10.2 environments that cannot be upgraded immediately, Splunk says administrators can mitigate by disabling the PostgreSQL sidecar service in $SPLUNK_HOME/etc/system/local/server.conf and restarting Splunk Enterprise:

[postgres]
disabled = true

That workaround is not free. Splunk warns not to apply it if the instance uses Edge Processor, OpAmp, or SPL2 data pipelines, because disabling PostgreSQL breaks those features and can cascade to dependent sidecar processes. In those environments, change approval needs to include both security urgency and application impact.

Check exposure and evidence, not just version numbers

CISA’s KEV entry says stakeholders are responsible for evaluating each asset’s internet exposure and following BOD 26-04 patching guidance. In practical terms, defenders should confirm whether vulnerable sidecar endpoints were reachable before patching, preserve logs around suspicious requests, and decide whether forensic triage is needed before assuming the upgrade closed the incident.

For non-federal organizations, the June 21 federal due date is still a useful benchmark. If a critical Splunk instance cannot be upgraded or safely mitigated before then, it should at least be isolated from untrusted networks while the fix is tested.

Sources

• SecurityWeek: Splunk Enterprise Vulnerability Exploited in Attacks Days After Disclosure
• Splunk advisory SVD-2026-0603 for CVE-2026-20253
• CISA alert: one known exploited vulnerability added to catalog
• CISA Known Exploited Vulnerabilities catalog JSON feed
• watchTowr technical analysis of CVE-2026-20253
• Featured image source: U.S. Navy network operations monitor on Wikimedia Commons

Featured image: Information systems personnel studying a monitor at Naval Network and Space Operations Command, photographed by Gary R. Wagner / U.S. Navy, public domain as a U.S. Navy work; cropped and converted to WebP for sxz.io.