Splunk Enterprise pre-auth RCE via unauthenticated PostgreSQL sidecar REST API proxied by web tier, CVSS 9.8

CVE-2026-20253, Splunk Enterprise: unauthenticated pre-auth RCE via the PostgreSQL sidecar proxy

CVE-2026-20253 (CVSS 9.8, CWE-306 Missing Authentication for Critical Function) is an unauthenticated remote code execution flaw in Splunk Enterprise 10.0.0–10.0.6 and 10.2.0–10.2.3 (Splunk SVD-2026-0603, 2026-06-10). watchTowr Labs, which published the full mechanism on 12 June, reports that Splunk-on-AWS is vulnerable out of the box because the PostgreSQL sidecar is enabled by default (watchTowr Labs, 2026-06-12). This brief's deep dive (§ 5) covers the sidecar-proxy chain, detection and patching in detail; fixed versions are 10.4.0, 10.2.4 and 10.0.7.

CVE Summary Table

(CVE-2026-10520 is carried as the § 0 Immediate Action and § 4 UPDATE; included here for the gate-clearing exploitation picture. CVEs that did not clear a § 2 inclusion gate this run, CVE-2026-47210 (vm2) and CVE-2026-12183 (BUK TS-G), are noted in § 7.)

Splunk Enterprise CVE-2026-20253: pre-auth RCE in the SIEM via an unauthenticated PostgreSQL sidecar proxy

The uncomfortable angle on this one is that the vulnerable software is the tool many readers use to find intrusions. CVE-2026-20253 (CVSS 9.8, CWE-306 Missing Authentication for Critical Function) is an unauthenticated remote code execution flaw in Splunk Enterprise, disclosed in Splunk's advisory SVD-2026-0603 on 10 June and dissected by watchTowr Labs on 12 June (Splunk SVD-2026-0603, 2026-06-10; watchTowr Labs, 2026-06-12). It affects Splunk Enterprise 10.0.0–10.0.6 and 10.2.0–10.2.3.

The mechanism. Recent Splunk Enterprise ships a PostgreSQL sidecar service (the splunk-postgres component) that exposes a Go-based REST API on loopback port 5435 (including /v1/postgres/recovery/backup and /v1/postgres/recovery/restore endpoints) and that internal API performs no authentication, on the assumption that only loopback callers can reach it (watchTowr Labs, 2026-06-12). The flaw is that Splunk's main web tier proxies those same endpoints outbound, at paths under /en-US/splunkd/__raw/v1/postgres/, so an external client can reach the no-auth database API by sending empty Basic credentials. From there an attacker writes attacker-controlled files into the sidecar's runtime directory and injects SQL into a crafted backup/restore payload, achieving code execution during the database restore step. watchTowr reports that Splunk Enterprise on AWS is vulnerable in its default configuration because the PostgreSQL sidecar is enabled out of the box, whereas on-premises Windows installs are exposed only where the sidecar has been explicitly enabled (watchTowr Labs, 2026-06-12).

Why the "loopback is safe" assumption fails. The root cause is a trust boundary that exists in the developers' mental model but not in the deployed architecture: the database API trusts the network (loopback-only) instead of the caller, and a second component (the web proxy) silently bridges that network gap. This is the recurring pattern watchTowr highlights; app-level auth was skipped because "the database has auth," but the proxy made the database reachable without it. The mapping is straightforward: T1190 (Exploit Public-Facing Application) for the initial unauthenticated reach, leading to execution on the host (T1059 Command and Scripting Interpreter). Because Splunk frequently runs with high privilege and aggregates logs from across the estate, a compromised indexer or search head is both an execution foothold and a route to the organisation's centralised security telemetry; an attacker who owns the SIEM can read what defenders see and potentially tamper with it.

Hunt and detection concepts. Splunk logs its own HTTP access, so the highest-value hunt is in _internal / the splunkd_access data: look for requests to /en-US/splunkd/__raw/v1/postgres/ paths, especially recovery/backup and recovery/restore, and for requests carrying empty or anonymous Basic-auth credentials from non-loopback source addresses. Unexpected PostgreSQL backup/restore operations in Splunk's operational logs outside a defined maintenance window are a second signal. On the host, watch for child processes spawned by the Splunk service account that are inconsistent with normal operation (shells, interpreters), and for new files appearing under the sidecar's pkg-run runtime path. Because this is the monitoring platform itself, forward Splunk's own access and audit logs to an independent collector so that a post-compromise log wipe on the box does not also erase the evidence of the intrusion.

Hardening and remediation. Upgrade to a fixed release, 10.4.0, 10.2.4 or 10.0.7 (Splunk SVD-2026-0603, 2026-06-10), and prioritise internet-facing and AWS-hosted deployments, the latter because watchTowr reports the sidecar is enabled there by default. On on-premises installs that do not need the PostgreSQL sidecar, confirm it is disabled and stays disabled after the upgrade. Network-side, no Splunk management or web interface should be exposed to the internet; restrict it to administrative networks and place it behind authenticated access controls. There is no reported in-the-wild exploitation at the time of writing, but a public technical analysis of a pre-auth RCE in a widely deployed SIEM closes the gap between disclosure and weaponisation quickly, treat this as an urgent change, not a routine one.