CISA Warns Critical Splunk Enterprise Flaw Is Being Exploited in Attacks

CISA has added a critical Splunk Enterprise vulnerability to its Known Exploited Vulnerabilities catalog after confirmation that attackers are exploiting the flaw in the wild. The issue, tracked as CVE-2026-20253, affects certain Splunk Enterprise 10.0 and 10.2 releases.

The vulnerability allows an unauthenticated attacker who can reach the affected service to create or truncate arbitrary files through a PostgreSQL sidecar service endpoint. Splunk rates the flaw as Critical with a CVSS 3.1 score of 9.8 in its SVD-2026-0603 advisory.

The risk is urgent because Splunk often sits at the center of security monitoring, logging, and investigation workflows. If attackers compromise a Splunk Enterprise server, they may disrupt visibility, tamper with files, or move toward deeper access inside the environment.

What CVE-2026-20253 affects

Splunk says CVE-2026-20253 affects Splunk Enterprise 10.2.0 through 10.2.3 and Splunk Enterprise 10.0.0 through 10.0.6. Splunk Enterprise 10.4, 9.4, and 9.3 are not affected.

The company also clarified that Splunk Cloud Platform is not affected because PostgreSQL sidecars are not used in Splunk Cloud. This matters because some early third-party summaries included Splunk Cloud before Splunk updated its advisory.

Researchers at watchTowr Labs analyzed the flaw and showed how the issue could be chained beyond basic file creation. Their work raised concern that the bug could become a practical remote code execution path in exposed environments.

Item	Details
CVE	CVE-2026-20253
Product	Splunk Enterprise
Vulnerable versions	10.2.0 to 10.2.3 and 10.0.0 to 10.0.6
Fixed versions	10.2.4, 10.0.7, and later supported fixed releases
Severity	Critical, CVSS 9.8
Weakness type	CWE-306, Missing Authentication for Critical Function
Cloud impact	Splunk Cloud Platform is not affected

How the Splunk Enterprise flaw works

The issue sits in a PostgreSQL sidecar service endpoint. Splunk says the endpoint lacked authentication controls, allowing a network-reachable user to invoke file operations without valid credentials.

In simple terms, a feature that should have been protected could accept requests from an unauthenticated user. That opens the door to arbitrary file creation or file truncation under the permissions available to the affected Splunk process.

Picus Security explained that attackers can target PostgreSQL sidecar recovery endpoints through Splunk’s web-facing path. That makes the flaw especially risky when Splunk Enterprise is reachable from untrusted networks.

CISA gives agencies a June 21 deadline

CISA added CVE-2026-20253 to the KEV catalog on June 18, 2026, with a remediation due date of June 21, 2026. The short deadline reflects the vulnerability’s active exploitation status and high technical impact.

Federal civilian executive branch agencies must follow CISA’s KEV requirements, but private organizations should treat the catalog as a priority signal as well. A Splunk server often stores sensitive operational, security, and application data, making it a high-value target.

The CISA KEV entry tells organizations to apply vendor instructions. For this vulnerability, the safest action is to upgrade Splunk Enterprise to a fixed version as quickly as possible.

Splunk recommends upgrading immediately

Splunk published fixes on June 10 and later updated the advisory on June 18 after its Product Security Incident Response Team became aware of limited exploitation. The Splunk advisory recommends upgrading to Splunk Enterprise 10.4.0, 10.2.4, 10.0.7, or later.

For organizations that cannot upgrade immediately, Splunk provides a mitigation that disables the PostgreSQL sidecar service. However, administrators need to use that workaround carefully because it can break Edge Processor, OpAmp, and SPL2 data pipelines.

Core search, indexing, and dashboard functionality are not affected by the mitigation, according to Splunk. Still, organizations should test the change in their own environment before applying it broadly to production systems.

• Upgrade affected Splunk Enterprise 10.2 systems to 10.2.4 or later.
• Upgrade affected Splunk Enterprise 10.0 systems to 10.0.7 or later.
• Confirm that Splunk Enterprise 9.4 and earlier systems are not mistakenly flagged as affected.
• Do not assume Splunk Cloud Platform is vulnerable to this issue.
• Disable the PostgreSQL sidecar only if an immediate upgrade is not possible and dependent features are not required.

Why researchers warn about remote code execution risk

The official Splunk description focuses on unauthenticated arbitrary file creation and truncation. However, security researchers quickly showed that file write behavior can become more dangerous when chained with application behavior and writable paths.

The watchTowr analysis described a pre-authentication exploitation path and released a detection artifact generator for defenders. That public research likely increased pressure on organizations to patch quickly.

Picus also warned that the flaw can be chained into remote code execution in affected deployments and that Splunk Enterprise on AWS should receive special attention where the vulnerable sidecar is enabled by default.

What administrators should check now

Administrators should first identify every Splunk Enterprise instance and confirm the exact version. They should also determine whether the server is reachable from the internet, a partner network, a user VLAN, or any other untrusted segment.

Next, teams should review logs for suspicious access to Splunk web paths that may proxy requests toward PostgreSQL sidecar recovery endpoints. Exploitation attempts may appear as unusual web requests rather than normal Splunk user activity.

Picus lists example endpoint paths and defensive validation steps that can help teams test whether controls detect attempts against CVE-2026-20253.

1. Inventory all Splunk Enterprise servers and record their versions.
2. Prioritize Splunk Enterprise 10.2.0 to 10.2.3 and 10.0.0 to 10.0.6.
3. Upgrade affected systems to fixed releases immediately.
4. Restrict access to Splunk web interfaces from untrusted networks.
5. Search logs for requests to PostgreSQL sidecar recovery paths.
6. Review filesystem activity for unexpected file creation or truncation.
7. Check whether any affected server supports Edge Processor, OpAmp, or SPL2 data pipelines before using the workaround.
8. Run incident response checks if the instance was exposed before patching.

Splunk systems need forensic review after patching

Patching closes the vulnerable path, but it does not prove that attackers did not already use it. Organizations with exposed or sensitive Splunk deployments should perform forensic review after upgrading.

Security teams should look for unexpected file changes, modified configuration files, suspicious app directories, strange scheduled tasks, new accounts, abnormal Splunk processes, and outbound connections from the Splunk host.

Because Splunk often stores the logs defenders use to investigate attacks, any suspected compromise should be handled carefully. Teams may need to compare Splunk data with independent endpoint, firewall, identity, and cloud logs to confirm whether telemetry was altered.

The bigger lesson for security infrastructure

CVE-2026-20253 is a reminder that security tools can become attacker targets. Monitoring platforms, SIEM systems, and log servers often hold privileged access, sensitive data, and broad visibility into the network.

Organizations should keep security infrastructure isolated, patched, monitored, and protected by strict access controls. No Splunk management interface should be casually exposed to the internet or broad internal user networks.

The urgency around CVE-2026-20253 comes from a simple combination: critical severity, no authentication, known exploitation, public technical analysis, and a product that many defenders rely on every day.

FAQ