Skip to content

Back to the catalog

watchTowr Labs: Splunk Enterprise CVE-2026-20253 Pre-Auth RCE via PostgreSQL Sidecar
labs.watchtowr.comwriteup

watchTowr Labs: Splunk Enterprise CVE-2026-20253 Pre-Auth RCE via PostgreSQL Sidecar

watchTowr Labs analyzes CVE-2026-20253, a pre-authentication vulnerability in the PostgreSQL sidecar service of Splunk Enterprise 10 and later. The sidecar's backup and restore API lacks authentication and is reachable through the main web interface. The write-up explains the root cause and which deployments are vulnerable by default, notably Splunk Enterprise on AWS, and shows how the flaw escalates to remote code execution. It also releases a non-exploitative detection script that tells vulnerable hosts from patched ones.

TL;DR watchTowr's analysis of Splunk Enterprise CVE-2026-20253, a pre-auth flaw in the PostgreSQL sidecar that escalates to RCE, with a detection script.
Document

What it is

CVE-2026-20253, a pre-auth arbitrary-file-write-to-RCE chain in Splunk Enterprise's PostgreSQL Sidecar Service (a ~66MB Go binary). Splunk advisory published June 10; CVSS 9.8; affects Splunk 10+. watchTowr's post carries the exploitation specifics the CVE text omits (the advisory only claims "file creation and truncation").

How it works

The sidecar binds 127.0.0.1:5435, but the main Splunk web app (all interfaces, port 8000) proxies to it via /en-US/splunkd/__raw/v1/postgres/... — so it is remotely reachable. /v1/postgres/recovery/backup and /restore pass the Basic-auth username straight into pg_dump -U / pg_restore -U (no app-level auth — any credentials accepted, even :), and pass the JSON database field as the trailing dbname. Postgres treats a dbname as a connection string whose parameters override the hardcoded -h localhost, so injecting hostaddr=, dbname=, and passfile= redirects the connection. The chain: read local .pgpass via passfile= to recover the postgres_admin password, dump an attacker-hosted DB to disk, then /restore it into template1 — the dump contains a SECURITY DEFINER PL/pgSQL function using lo_from_bytea/lo_export that fires during restore to write an arbitrary file.

Preconditions / Affected

  • Splunk Enterprise on AWS: sidecar installed and enabled by default — vulnerable out of the box.
  • On-prem Windows manual install: sidecar not installed, or installed but not enabled by default.
  • Splunk versions 10 and above (sidecar concept introduced in v10).

What to do

RCE is achieved by overwriting a Splunk-executed Python script:

/opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py

with e.g. import os; os.system("id > .../watchTowr.txt"). The credential file lived at /opt/splunk/var/packages/data/postgres/.pgpass (revealing user postgres_admin).

Detection — watchTowr's neutered Detection Artefact Generator (watchTowr-vs-Splunk-RCE-CVE-2026-20253.py) just probes the endpoint with arbitrary Authorization credentials:

python3 watchTowr-vs-Splunk-RCE-CVE-2026-20253.py -H http://vulnerable.splunk.lab:8000 -r en-US
  • 400 status → VULNERABLE (endpoint reachable, not blocked)
  • 401 status → not vulnerable

Patch to a fixed release per Splunk's advisory; if unable, restrict/disable the sidecar service.

Caveats

The file-write primitive alone is what the advisory documents; the connection-string injection, .pgpass exfiltration, and lo_export RCE are watchTowr's own reproduction. The published DAG only detects exposure and does not weaponize.

CVEs named here

Technologies named here

Techniques named here

  • Unauthenticated access to internal API via proxy
  • Path traversal for arbitrary file creation/truncation
  • PostgreSQL connection string parameter injection
  • Forced out-of-band database connection
  • Credential/passfile disclosure via local .pgpass abuse
  • Malicious database dump for code execution during restore
  • Arbitrary file write to achieve RCE
  • Path traversal