CVE-2026-20253: Splunk Enterprise's Unauthenticated Postgres Sidecar — What Defenders Should Do

Correction (September 2026): an earlier version of this post treated CVE-2026-20253 as a Cisco network-device advisory and left several values marked for verification. That was wrong. CVE-2026-20253 is a Splunk Enterprise vulnerability (Splunk is part of Cisco, and Cisco's PSIRT is the CVE Numbering Authority for the record, hence the 2026-20xxx ID). This version is rewritten against the vendor advisory, NVD and the CISA KEV entry, all linked at the end.

TL;DR

• What: Missing authentication (CWE-306) on a PostgreSQL sidecar service endpoint in Splunk Enterprise. Per Splunk, any network-reachable user can create or truncate arbitrary files without credentials.
• Severity: CVSS 3.1 9.8 Critical (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H).
• Affected: Splunk Enterprise 10.0.0–10.0.6 and 10.2.0–10.2.3. Versions 9.4 and earlier, and 10.4, are not affected. Splunk Cloud Platform is not affected.
• Fixed in: 10.0.7, 10.2.4, 10.4.0 or later.
• Exploited: Splunk PSIRT reported limited exploitation in June 2026. CISA added it to the Known Exploited Vulnerabilities catalog on 2026-06-18, with a federal due date of 2026-06-21.

Timeline

Date (2026)	Event
Jun 10	Splunk publishes advisory SVD-2026-0603; the CVE is published to NVD
Jun 12	watchTowr Labs publishes a pre-auth RCE chain built on the bug; Splunk clarifies that Splunk Cloud is not affected
Jun 15	Splunk adds the "disable PostgreSQL" workaround to the advisory
Jun 18	Splunk notes limited in-the-wild exploitation; CISA adds the CVE to KEV
Jun 21	CISA KEV due date for US federal agencies

How it works (short version)

Splunk Enterprise 10.x includes "sidecar" services that run alongside splunkd, including a PostgreSQL sidecar with a small HTTP API for backup and restore. The vendor description is simple: that endpoint has no authentication controls, so anyone who can reach it can trigger file operations.

watchTowr's public analysis filled in the details:

• The sidecar listened only on localhost (port 5435 in their lab), but Splunk Web proxied requests to it under /<locale>/splunkd/__raw/v1/postgres/recovery/backup and /restore.
• The endpoints accepted any HTTP Basic credentials, including empty ones.
• The backupFile parameter allowed path traversal, which gives the vendor's "create or truncate arbitrary files" primitive.
• The database parameter was passed to pg_dump / pg_restore and could carry a PostgreSQL connection string (e.g. hostaddr=, passfile=). That let them pull a dump from an attacker-controlled database, restore it locally using credentials from Splunk's own .pgpass file, and turn it into an arbitrary file write as the splunk user. From there they got code execution by overwriting a Python script that Splunk runs on a schedule.
• Default exposure depends on how Splunk was deployed. In their testing, Splunk Enterprise on AWS had the sidecar installed and enabled out of the box.

The vendor advisory itself only claims file creation/truncation. The RCE chain comes from the third-party research. Either way, the CVSS 9.8 rating and the KEV listing mean you treat it as critical.

What to do

1. Find every affected instance

Check all Splunk Enterprise nodes: search heads, indexers, heavy forwarders, deployment servers, cluster managers. On each host:

$SPLUNK_HOME/bin/splunk version

Or from a search head, for the peers it can see:

| rest /services/server/info splunk_server=*
| table splunk_server version

Anything on 10.0.0–10.0.6 or 10.2.0–10.2.3 is in scope.

2. Patch, or apply the vendor workaround

Upgrade to 10.0.7, 10.2.4, 10.4.0 or later. If you can't upgrade right away, Splunk's documented workaround is to disable the PostgreSQL sidecar in $SPLUNK_HOME/etc/system/local/server.conf and restart:

[postgres]
disabled = true

Splunk's caveat: don't apply this on instances that use Edge Processor, OpAmp or SPL2 data pipelines, because disabling PostgreSQL breaks those features and can cascade to dependent sidecars. Core search, indexing and dashboards aren't affected.

3. Cut exposure

The attack goes through Splunk Web. If Splunk Web is reachable from the internet, or from broad internal networks, restrict it to admin networks or a VPN now, patched or not. A SIEM console shouldn't be internet-facing.

4. Confirm exposure safely

watchTowr published a detection-only check that tells vulnerable and patched instances apart by the HTTP status the proxied endpoint returns when sent any credentials: 400 means vulnerable (the endpoint was reached and the credentials weren't validated), 401 means not vulnerable. Only run it against systems you own or are authorized to test.

5. Hunt, and assume compromise if you were exposed

If a vulnerable instance was reachable before you patched, investigate it rather than just patching and moving on. With confirmed in-the-wild exploitation and a public exploit chain, "patched" doesn't mean "clean". Starting points, adapted from the public exploitation details:

Access logs: look for requests to the recovery endpoints. A starting query (confirm field names in your version):

index=_internal (sourcetype=splunk_web_access OR sourcetype=splunkd_access) "/v1/postgres/recovery/"
| stats count min(_time) as first_seen max(_time) as last_seen values(status) as status by host, clientip
| convert ctime(first_seen) ctime(last_seen)

A successful attacker runs as the splunk user and can tamper with local logs. Check a copy you trust as well: reverse-proxy, load-balancer or WAF logs in front of Splunk Web.

Process telemetry (EDR): pg_dump or pg_restore launched by Splunk's sidecar with hostaddr=, passfile= or ../ in the command line, or writing output outside the sidecar's own directory ($SPLUNK_HOME/var/run/supervisor/pkg-run/).

Network: outbound connections from Splunk hosts to external PostgreSQL servers (TCP 5432). The public chain relies on Splunk connecting out to an attacker's database.

File integrity: unexpected changes to scripts under $SPLUNK_HOME/etc/apps/*/bin/, and new files in the Splunk Web static directory ($SPLUNK_HOME/share/splunk/search_mrsparkle/exposed/). The public PoC used both.

If any of these hit, handle the host as a compromised security system: isolate it, preserve disk and memory, rotate credentials Splunk holds (service accounts, API tokens, forwarder and deployment credentials), and review whether detections or alerting were changed.

Why this one matters more than the CVSS score suggests

Compromising the SIEM gives an attacker something most footholds don't: visibility into what you can detect and a way to quietly blind you. The root cause is also a pattern worth watching across your whole stack: a "localhost-only" helper service that the internet-facing web tier proxies without its own authentication. When a vendor ships new sidecars or agents, ask how they authenticate and what can reach them.

Sources

• Splunk advisory SVD-2026-0603: https://advisory.splunk.com/advisories/SVD-2026-0603
• NVD, CVE-2026-20253: https://nvd.nist.gov/vuln/detail/CVE-2026-20253
• CISA Known Exploited Vulnerabilities catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-20253
• watchTowr Labs, "Why Use App-Level Auth When Every Database Has Auth? (Splunk Enterprise CVE-2026-20253 Pre-Auth RCE)": https://labs.watchtowr.com/why-use-app-level-auth-when-every-database-has-auth-splunk-enterprise-cve-2026-20253-pre-auth-rce/