Skip to content
Splunk Enterprise RCE (CVE-2026-20253) | ThreatLabz

Splunk Enterprise RCE (CVE-2026-20253) | ThreatLabz

Zscaler June 26, 2026

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.

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

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

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.

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.

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.

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.

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 scheduled execution, resulting in unauthenticated RCE.

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.

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.

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.

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.

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

Recommended Mitigation

Minimize the external attack surface

Prevent lateral threat movement

Inspect outbound traffic across channels with Zscaler DLP .

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

Zscaler Advanced Threat Protection

Zscaler Private Access AppProtection

Disclaimer: This blog post has been created by Zscaler for informational purposes only and is provided "as is" without any guarantees of accuracy, completeness or reliability. Zscaler assumes no responsibility for any errors or omissions or for any actions taken based on the information provided. Any third-party websites or resources linked in this blog post are provided for convenience only, and Zscaler is not responsible for their content or practices. All content is subject to change without notice. By accessing this blog, you agree to these terms and acknowledge your sole responsibility to verify and use the information as appropriate for your needs.

Extracted Entities

Domains (1)