CISA added CVE-2026-20253 to its Known Exploited Vulnerabilities catalog on June 18, 2026, confirming active exploitation of a CVSS 9.8 unauthenticated remote code execution vulnerability in Splunk Enterprise. Federal agencies face a mandatory remediation deadline of June 21. Commercial organisations should treat this timeline as a hard target: Splunk deployments at security operations centres, financial institutions, healthcare systems, and government agencies represent extremely high-value targets for pre-ransomware access and espionage activity.
What the Vulnerability Does
CVE-2026-20253 is a missing authentication vulnerability (CWE-306) in Splunk Enterprise’s PostgreSQL sidecar service. The sidecar exposes administrative backup and restore endpoints that perform no authentication checks. Any attacker with network access to the sidecar service port can invoke these endpoints and supply connection parameters pointing to an attacker-controlled PostgreSQL server.
The attack chain from there is direct. The sidecar connects to the attacker’s PostgreSQL instance and the attacker uses PostgreSQL’s lo_export() function to write arbitrary content to arbitrary filesystem paths on the Splunk host. With file write capability on a Splunk server, the path to code execution is straightforward: overwrite a Python script that Splunk executes automatically as part of its modular input initialisation cycle. The target identified in post-advisory analysis is /opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py. Overwriting this file with attacker-controlled Python delivers execution on the next Splunk restart or modular input cycle, running as the Splunk service account.
The truncation capability is a separate concern. The same unauthenticated endpoint can truncate arbitrary files, enabling an attacker to corrupt logs, destroy forensic evidence, or disable security controls before or after primary exploitation.
Exposure Profile
Splunk Enterprise on AWS is particularly exposed. The PostgreSQL sidecar is enabled by default on AWS deployments, bound to interfaces that may be accessible from within the AWS environment or, in misconfigured configurations, from the internet. On-premise deployments may have the sidecar disabled or the port network-isolated depending on configuration, but organisations should verify this before assuming reduced risk.
Affected versions:
- Splunk Enterprise 10.2.x below 10.2.4
- Splunk Enterprise 10.0.x below 10.0.7
Splunk Enterprise 9.4 and earlier are not affected (the PostgreSQL sidecar does not exist in those releases). Splunk Cloud Platform is managed directly by Splunk and does not require customer patching.
Why Splunk Specifically
Splunk Enterprise is deployed at the organisations attackers most want to compromise: SOCs, government agencies, financial institutions, and critical infrastructure operators. A compromised Splunk instance gives an attacker comprehensive visibility into an organisation’s security monitoring posture, active alert rules, threat detection logic, log sources, and infrastructure topology. The forensic value is immense for pre-ransomware reconnaissance, and the ability to blind or manipulate Splunk’s logging creates opportunities to operate undetected during subsequent lateral movement.
CISA’s ransomware campaign association field is marked “Unknown” for this KEV entry, suggesting the observed exploitation may involve initial access brokers, targeted espionage activity, or pre-ransomware positioning rather than confirmed ransomware deployment. The absence of a ransomware link does not diminish urgency: access brokering activity for high-value targets frequently precedes ransomware deployment by weeks.
Recommended Actions
Primary remediation: Upgrade to Splunk Enterprise 10.4.0, 10.2.4, or 10.0.7. Federal agencies must complete this by June 21; commercial organisations should match this timeline.
Immediate triage steps:
- Determine whether the PostgreSQL sidecar is running (
ps aux | grep postgresql) - Identify which network interfaces the sidecar port is bound to (
ss -tlnp | grep splunk) - If the sidecar is running and reachable from untrusted segments, apply host-based firewall rules to restrict access while patching is expedited
- If disabling is feasible, consult Splunk advisory SVD-2026-0603 for the precise configuration key
Detection: Monitor for file modifications to Splunk Python scripts in /opt/splunk/etc/apps/*/bin/*.py, particularly outside maintenance windows. Outbound connections from the Splunk host to external PostgreSQL servers (port 5432) are a strong indicator of exploitation activity. Review splunkd.log for references to postgresql, sidecar, or lo_export.