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

Splunk Enterprise contains a critical authentication bypass vulnerability that enables unauthenticated remote code execution. CVE-2026-20253, rated 9.8 on CVSS, affects versions below 10.0.7 and 10.2.4 through exposed PostgreSQL sidecar service endpoints that lack authentication controls. Any network-reachable attacker can invoke file operations and ultimately execute arbitrary code without credentials.

The vulnerability exists in the PostgreSQL sidecar service that Splunk Enterprise uses internally. Two specific endpoints—/v1/postgres/recovery/backup and /v1/postgres/recovery/restore—accept requests from any user without authentication. Cisco-owned Splunk disclosed the flaw this week and confirmed Splunk Cloud is not affected because it does not use PostgreSQL sidecars in its architecture.

Exploit Chain: From Database Dump to Code Execution

WatchTowr Labs published a detailed technical breakdown on Friday showing how CVE-2026-20253 can be weaponized for pre-authenticated remote code execution. Security researchers Piotr Bazydlo and Yordan Ganchev demonstrated a three-stage attack chain that leverages PostgreSQL's native functions to achieve arbitrary file write, then escalates to code execution.

The attack begins by connecting to an attacker-controlled PostgreSQL database and using the /backup endpoint to dump its contents into an arbitrary file on the Splunk file system. Next, the attacker uses the /restore endpoint with a 'passfile' argument pointing to /opt/splunk/var/packages/data/postgres/.pgpass—a file containing the password for the postgres_admin user. This allows the attacker to load their malicious database dump into Splunk's local PostgreSQL instance.

During the restoration process, any SQL queries defined in the attacker's database dump are executed by Splunk's PostgreSQL instance. The researchers created a database dump template that defines a malicious function using lo_export—a PostgreSQL function that extracts a BLOB from the database and writes it as a file on the file system. This gives the attacker arbitrary file write capability on the Splunk server.

From File Write to Remote Code Execution

Once arbitrary file write is achieved, escalation to remote code execution is straightforward. The attacker overwrites a Python script that Splunk frequently executes, such as /opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py, with malicious payload code. When Splunk next executes this script in the normal course of operations, the attacker's code runs with Splunk's privileges.

The complete attack sequence requires just three HTTP requests: one to backup an attacker-controlled database onto the Splunk file system, one to restore that malicious dump and trigger the lo_export function to write a Python payload, and waiting for Splunk to execute the compromised script. WatchTowr Labs noted they configured their proof-of-concept database to allow authentication without a password and granted sufficient permissions to invoke functions like lo_export.

Affected Versions and Patches

Splunk has released patches for all affected versions. Organizations must upgrade immediately to one of the following:

• Splunk Enterprise 10.0.0 through 10.0.6: Upgrade to 10.0.7
• Splunk Enterprise 10.2.0 through 10.2.3: Upgrade to 10.2.4
• Splunk Enterprise 10.4: Not affected by this vulnerability
• Splunk Cloud: Not affected (does not use PostgreSQL sidecars)

The vulnerability only affects Splunk Enterprise installations that use PostgreSQL sidecar services. This component is not present in Splunk Cloud Platform, which means cloud customers face no risk from this specific flaw. However, the vast attack surface of an exposed, unauthenticated database management endpoint makes this a critical priority for all on-premises Enterprise deployments.

Threat Landscape and Urgency

Splunk reports no evidence of CVE-2026-20253 being exploited in the wild as of this disclosure. However, the publication of detailed exploit mechanics by watchTowr Labs significantly raises the risk of opportunistic attacks. Security teams should assume that functional exploit code will be integrated into automated scanning and exploitation frameworks within days.

The high value of Splunk deployments as intelligence targets makes this vulnerability particularly attractive to both financially motivated threat actors and advanced persistent threat groups. Organizations that use Splunk Enterprise for security monitoring face a compounding risk: the tool designed to detect intrusions becomes the vector for initial access.

Mitigation Priorities

Patching to version 10.0.7, 10.2.4, or 10.4 is the only complete mitigation. Organizations unable to patch immediately should implement network-level access controls to restrict connectivity to Splunk Enterprise instances. The vulnerable endpoints are reachable over the network, so placing Splunk servers behind strict firewall rules or VPNs can reduce exposure until patching is complete.

Security teams should also review logs for unusual activity on the /v1/postgres/recovery/backup and /v1/postgres/recovery/restore endpoints. Look for requests from unexpected source IPs, especially external addresses. Monitor for unexpected changes to Python scripts in /opt/splunk/etc/apps/ directories and unusual PostgreSQL connection activity from external hosts.

Given the CVSS 9.8 severity, the availability of public exploit details, and the strategic value of Splunk deployments, organizations should treat this as a patch-now scenario. The combination of no authentication requirement and straightforward escalation to remote code execution makes CVE-2026-20253 one of the highest-priority vulnerabilities disclosed this quarter.