CVE-2026-20253: Splunk Enterprise — Unauthenticated PostgreSQL Sidecar RCE

Background

CVE-2026-20253 is a CVSS 9.8 critical missing authentication vulnerability in Splunk Enterprise’s PostgreSQL sidecar service. An unauthenticated attacker with network access to the sidecar service port can create or truncate arbitrary files on the Splunk host. When chained with PostgreSQL’s lo_export function — a standard feature available through the attacker-controlled database connection the vulnerability enables — the file write becomes remote code execution by overwriting a Python script that Splunk executes automatically.

CISA added CVE-2026-20253 to the Known Exploited Vulnerabilities catalog on June 18, 2026, with a mandatory remediation deadline of June 21, 2026 for US federal agencies. Commercial organisations should treat this as a critical priority. The PostgreSQL sidecar is enabled by default in Splunk Enterprise deployments on AWS, meaning cloud-hosted Splunk instances are exposed out of the box without explicit configuration.

Technical Mechanism

The PostgreSQL sidecar service exposes a set of administrative endpoints for database backup and restore operations. These endpoints perform no authentication checks — CWE-306, Missing Authentication for Critical Function. Any client that can reach the service port can invoke backup and restore operations without credentials.

The backup and restore endpoints accept attacker-supplied configuration, including connection parameters for an external PostgreSQL instance. An attacker can instruct the sidecar to connect to an attacker-controlled PostgreSQL server, then use the PostgreSQL lo_export() function — which exports a Large Object (BLOB) to the filesystem — to write arbitrary content to arbitrary paths on the Splunk host. lo_export() is standard PostgreSQL functionality and runs in the context of the PostgreSQL server connection. When the sidecar initiates the connection to the attacker’s PostgreSQL instance, the attacker controls what that server asks the client to do during the restore process, including invoking lo_export() with attacker-specified content and target path.

With an arbitrary file write primitive, code execution follows by targeting a file that Splunk executes automatically as part of normal operation. The primary target identified in post-advisory analysis is:

/opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py

Splunk executes this Python script as part of its modular input initialisation. Overwriting it with attacker-controlled Python code causes the payload to execute on the next Splunk restart or modular input cycle, with the privileges of the Splunk service account (typically splunk on Linux, which may have elevated local system access depending on deployment configuration).

The truncation capability is a separate impact: the same unauthenticated endpoint can truncate arbitrary files, which can be used to corrupt logs, disable security controls, or cause denial of service.

On-premise Splunk Enterprise deployments may have the sidecar disabled depending on configuration, and the service port may not be internet-accessible. However, Splunk Enterprise deployments on AWS have the PostgreSQL sidecar enabled by default, with the service bound to interfaces that may be reachable from within the AWS environment or, in misconfigured deployments, from the internet. The attack requires network access to the sidecar service port, not the standard Splunk web UI port (8000) or Splunk-to-Splunk communication port (9997). Defenders should verify whether the sidecar service is running and what network interfaces it is bound to as a first triage step.

Real-World Exploitation Evidence

CISA’s KEV addition on June 18, 2026 confirms that exploitation activity has been observed. CISA designates vulnerabilities for KEV listing only when evidence of active exploitation exists. The ransomware campaign association field is marked “Unknown” in the CISA entry, suggesting the observed exploitation may be pre-ransomware access brokering, targeted espionage, or early-stage criminal activity rather than confirmed ransomware deployment.

Splunk Enterprise is deployed at high-value targets: security operations centres, financial institutions, healthcare organisations, and government agencies. It holds log data from across the organisation and typically has broad network access to log sources. A compromised Splunk instance provides the attacker with extensive visibility into the organisation’s security posture, active alerts, and infrastructure, making it an attractive target for pre-ransomware reconnaissance and for actors seeking to blind defensive monitoring.

No public proof-of-concept exploit code was published at the time of the CISA KEV addition, but the attack chain is straightforward to replicate from the vulnerability description.

Impact Assessment

Splunk Enterprise holds an organisation’s security telemetry and log data, providing visibility into virtually all internal systems. Compromise of a Splunk instance gives attackers extensive knowledge of the organisation’s security posture, active detections, and network topology — intelligence that directly enables evasion and lateral movement.

The file write-to-RCE chain achieves code execution under the Splunk service account, which typically has broad network and filesystem access to log sources. Beyond data exfiltration, attackers can manipulate Splunk to suppress alerts or corrupt the forensic record. The AWS default-enabled exposure of the vulnerable sidecar means cloud-hosted Splunk deployments face network-accessible attack surface out of the box. SOC teams and security operations centers are the primary high-value targets given Splunk’s centrality to defensive monitoring.

Affected Versions

Remediation Steps

1. Upgrade Splunk Enterprise: Apply the fixed release for your branch — 10.2.4 or 10.4.0 for 10.2.x deployments, 10.0.7 or 10.4.0 for 10.0.x deployments. The CISA federal remediation deadline was June 21, 2026; commercial organisations should treat this as an equivalent priority given confirmed exploitation.

2. Disable the PostgreSQL sidecar service (workaround): If immediate patching is not feasible, disable the sidecar. Consult Splunk advisory SVD-2026-0603 for the precise configuration key to disable the service without disrupting KV Store. Verify the sidecar is no longer running after the change:

   ps aux | grep postgresql
   ss -tlnp | grep -E 'splunk|postgres'

3. Apply network-level controls: If disabling the service is not immediately possible, restrict access to the sidecar service port using host-based firewall rules or network ACLs. The sidecar service should not be reachable from untrusted networks. Confirm the port in your deployment via netstat -tlnp | grep splunk.

4. Review Splunk Cloud Platform exposure: Splunk Cloud Platform is patched through Splunk’s managed update process and does not require separate customer action. Confirm your environment’s update status via the Splunk Cloud admin console.

Detection Guidance

Connections to the PostgreSQL sidecar port from unexpected sources are the primary indicator. In deployments where the sidecar should only be accessed by internal Splunk processes, any external connection to the sidecar port warrants investigation:

# Check listening ports for sidecar service
ss -tlnp | grep -E 'splunk|postgres'

# Review connections to sidecar port
netstat -an | grep <sidecar_port>

Monitor for modifications to Splunk Python scripts in the apps directory, particularly modular input scripts. File integrity monitoring on these paths should alert on unexpected modifications, especially outside of known maintenance windows:

/opt/splunk/etc/apps/*/bin/*.py
/opt/splunk/etc/apps/splunk_secure_gateway/bin/

Review splunkd.log and the audit index for unusual database backup or restore operations. Look for log entries referencing the PostgreSQL sidecar making outbound connections to unexpected hosts:

index=_internal sourcetype=splunkd "postgresql" OR "sidecar" OR "lo_export"
| stats count by host, _time, message

At the time of writing, specific IOCs associated with in-the-wild exploitation have not been published. Defenders should check for unexpected modifications to Splunk Python scripts (particularly ssg_enable_modular_input.py), outbound connections from the Splunk host to external PostgreSQL servers (port 5432), truncated or zeroed log files indicating tampering, and new Splunk user accounts or changed credentials in the authentication configuration.

Timeline

References

• Splunk Security Advisory SVD-2026-0603
• CISA KEV: CVE-2026-20253
• Orca Security: CVE-2026-20253 Splunk Enterprise RCE and File Operation Flaws
• Resecurity: CVE-2026-20253 Splunk Enterprise Pre-Authentication Remote Code Execution
• NetSPI: CVE-2026-20253 Splunk Enterprise Overview and Takeaways
• NVD: CVE-2026-20253