Splunk Enterprise CVE-2026-20253: PostgreSQL Sidecar Flaw Enables Unauthenticated RCE

The Flaw

Splunk has shipped security updates for CVE-2026-20253, a critical vulnerability in Splunk Enterprise rated 9.8 on CVSS. The bug lets an unauthenticated, network-reachable attacker create or truncate arbitrary files on the underlying host through a PostgreSQL sidecar service bundled with the product. The root cause is blunt: the sidecar's service endpoint enforces no authentication, so anyone who can reach it over the network can invoke file operations without credentials.

Splunk, now part of Cisco, confirmed the flaw in advisory SVD-2026-0603. Splunk Cloud is not affected - the managed product does not use Postgres sidecars.

From File Write to Remote Code Execution

On June 13, watchTowr Labs published a full technical breakdown showing the file-write primitive escalates cleanly to pre-authenticated remote code execution. The chain abuses two recovery endpoints exposed by the sidecar: /v1/postgres/recovery/backup and /v1/postgres/recovery/restore.

The sequence researchers Piotr Bazydlo and Yordan Ganchev demonstrated:

• Stand up an attacker-controlled PostgreSQL database configured to allow passwordless authentication, with permissions to call functions like lo_export.
• Hit the /backup endpoint to dump that remote database onto the Splunk host's filesystem.
• Hit the /restore endpoint with a passfile argument pointing at Splunk's local .pgpass file (/opt/splunk/var/packages/data/postgres/.pgpass), which holds the password for the postgres_admin account. This authenticates the attacker to the local PostgreSQL instance.
• The restore loads the attacker's database dump, which defines a malicious function using lo_export to write attacker-controlled content to disk. The function executes during the restore process.

With an arbitrary file-write primitive on the Splunk filesystem, escalation to code execution is trivial: overwrite a Python script that Splunk runs on a schedule - watchTowr used /opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py - and wait for Splunk to execute the payload.

Affected and Fixed Versions

• Splunk Enterprise 10.0.0 through 10.0.6 - fixed in 10.0.7
• Splunk Enterprise 10.2.0 through 10.2.3 - fixed in 10.2.4
• Splunk Enterprise 10.4 - not affected
• Splunk Cloud - not affected

Exposure

Splunk sits at the center of enterprise security operations, which makes any pre-auth RCE in the on-prem product a high-value target. Internet-facing deployments are the immediate concern, but the sidecar is reachable by anything on the same network segment, so internal exposure matters too - an attacker with a foothold inside the perimeter can pivot straight to the SIEM. Compromising Splunk does not just hand over an application; it hands over the log data, the detection logic, and frequently the credentials the security team depends on.

Exploitation Status

There is no evidence of in-the-wild exploitation as of publication. That window rarely stays open. With a public technical writeup and a documented exploitation path, opportunistic scanning and attempts typically follow within days. Treat the absence of confirmed attacks as a head start, not a reason to wait.

Action Items

• Patch immediately. Upgrade to Splunk Enterprise 10.0.7 (10.0.x branch) or 10.2.4 (10.2.x branch). These are the only fixed releases.
• If you cannot patch right now, block network access to the sidecar recovery endpoints. The /v1/postgres/recovery/backup and /v1/postgres/recovery/restore paths must not be reachable from untrusted networks.
• Verify no Splunk Enterprise management or sidecar interfaces are exposed to the internet. Put them behind a VPN or firewall if they are.
• Hunt for abuse: review access logs for requests to /v1/postgres/recovery/*, and check for unexpected modifications to Splunk-executed Python scripts under /opt/splunk/etc/apps/.
• Splunk Cloud customers do not need to act on this CVE; the sidecar is not present in the managed product.