CVE-2026-20253 is a critical (CVSS 9.8) unauthenticated remote code execution vulnerability in Splunk Enterprise, disclosed by Splunk PSIRT on June 10, 2026 as advisory SVD-2026-0603 and officially described as 'unauthenticated arbitrary file creation and truncation' via a PostgreSQL sidecar service endpoint. Splunk Enterprise ships an optional PostgreSQL 'sidecar' database used to support Edge Processor, OpAmp, and SPL2 data-pipeline features. This sidecar is meant to be reachable only on localhost (127.0.0.1:5435), but Splunk Web (the main HTTP interface on TCP 8000) reverse-proxies requests to sidecar recovery endpoints — including `/en-US/splunkd/__raw/v1/postgres/recovery/backup` — making the internal service remotely reachable. On AWS deployments the sidecar is enabled by default, broadening exposure versus on-premise installs where it must be explicitly enabled.

The recovery endpoint expects an HTTP Basic Authorization header but performs no real validation of the supplied credentials: a request carrying `Authorization: Basic Og==` (base64 for a blank `:` — empty username and password) is accepted and the backup operation is invoked. From there, watchTowr Labs (technical write-up and public PoC published June 12, 2026) demonstrated a multi-stage chain from this authentication bypass to full RCE:

1. **Unauthenticated trigger** — attacker sends an unauthenticated POST to the recovery/backup endpoint with an empty Basic-auth header. 2. **Path traversal / arbitrary file write** — the `backupFile` request parameter is passed directly to `pg_dump` as an output path with no directory constraint, so traversal sequences such as `../../../../../../tmp/backuptest` let the attacker write files anywhere the Splunk service account can reach. 3. **Connection-string injection** — because `pg_dump`/`pg_restore` are invoked with attacker-influenced libpq connection parameters, the attacker can inject `hostaddr=`, `dbname=`, `port=`, and `passfile=` values to redirect the sidecar's database connection to an attacker-controlled PostgreSQL server, causing the backup/restore machinery to pull attacker-supplied content. 4. **Credential disclosure** — the sidecar stores its own connection credentials in plaintext at `/opt/splunk/var/packages/data/postgres/.pgpass`, letting an attacker who can read arbitrary files authenticate directly to the sidecar as the privileged `postgres_admin` role. 5. **Backup/restore abuse and large-object export** — using `pg_restore` against an attacker-crafted dump (or PostgreSQL large-object export via `lo_export`), the attacker writes arbitrary file content to the filesystem during 'restoration', not merely truncating files. 6. **Persistence/code execution via scheduled script hijack** — the attacker overwrites a Splunk-scheduled Python modular-input script, `/opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py`, with attacker-controlled code. When Splunk next invokes that modular input, the payload executes under the Splunk service account, completing the chain from zero authentication to full remote code execution.

Affected versions are Splunk Enterprise 10.2.0–10.2.3 and 10.0.0–10.0.6; versions 9.4 and earlier are unaffected, and Splunk Cloud Platform is not affected because it does not use PostgreSQL sidecars. Splunk shipped fixes in 10.2.4, 10.0.7, and 10.4.0+. CrowdSec deployed a detection scenario on June 15, 2026; the first real-world exploitation attempts were observed June 17, 2026, and by June 18 both Splunk PSIRT and CISA confirmed active in-the-wild exploitation, with CISA adding CVE-2026-20253 to the KEV catalog and ordering FCEB agencies to remediate by June 21/22 (reported variously as June 21–23), 2026 under Binding Operational Directive 26-04. CrowdSec's global sensor network flagged 20 unique malicious IP addresses attempting exploitation in the initial days after public disclosure of active attacks; Shadowserver separately reported roughly 1,400 internet-exposed Splunk instances globally (952 in North America, 223 in Europe), though the proportion still running vulnerable versions is unconfirmed. No specific threat actor or APT group has been publicly attributed; activity to date is consistent with opportunistic, automated mass-exploitation enabled by the low complexity of the exploit and the public availability of PoC and Nuclei detection/scanning templates.

Beyond the initial file-write primitive, Zscaler ThreatLabz's June 26, 2026 deep-dive confirms the sidecar also exposes a second reverse-proxied endpoint, `/en-US/splunkd/__raw/v1/postgres/recovery/restore`, abused analogously to `/recovery/backup` to trigger `pg_restore`-driven file writes. Zscaler's post-exploitation analysis states that once an attacker gains code execution, they 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' — turning a compromised Splunk instance into both an anti-forensics tool against the victim's own SIEM/logging pipeline and a lateral-movement pivot point across the monitored environment, since Splunk indexers/search heads typically hold credentials, tokens, and connectivity to many internal hosts. Defenders can add an interim workaround stanza (`[postgres]` / `disabled = true`) to `$SPLUNK_HOME/etc/system/local/server.conf` to disable the sidecar entirely, though this breaks Edge Processor, OpAmp, and SPL2 pipelines and is explicitly not a substitute for patching. Zscaler has released a network-layer detection signature (`App.Exploit.CVE-2026-20253` for Advanced Threat Protection customers) and a ZTNA-layer rule (Private Access AppProtection signature `6000500`) covering exploitation attempts, complementing the previously released Snort signature (SID 1.2069930.1) and CrowdSec detection scenario. Multiple independent vendor write-ups (Zscaler, Picus Security, NetSPI, watchTowr Labs, and Splunk's own advisory) consistently confirm Splunk Cloud Platform is NOT affected because it does not deploy PostgreSQL sidecars — only self-managed Splunk Enterprise deployments are vulnerable.