Splunk has patched CVE-2026-20253, a critical (CVSS 9.8) flaw in Splunk Enterprise that lets an unauthenticated, network-reachable attacker write files on the host and chain that into remote code execution. watchTowr Labs published the full technical breakdown on Friday, so the exploitation window is open even though no in-the-wild activity has been reported yet. If you run Splunk Enterprise on-prem — and especially if you run it on AWS — treat this as a patch-tonight item. The target here is the box that holds every log and credential your SOC relies on.

What happened

Splunk 10 introduced a PostgreSQL “sidecar” service to back some of the platform’s internal data. That sidecar exposes a small recovery API on local port 5435 — but Splunk’s main web application proxies those endpoints, and the proxy applies no authentication. The result: anyone who can reach the Splunk web port can invoke the sidecar’s /v1/postgres/recovery/backup and /v1/postgres/recovery/restore endpoints with no credentials at all. Splunk’s advisory (SVD-2026-0603) describes the primitive plainly — “an unauthenticated user could create or truncate arbitrary files through a PostgreSQL sidecar service endpoint.”

Technical details

watchTowr’s Piotr Bazydlo and Yordan Ganchev turned that file primitive into clean pre-auth RCE. The chain is a tidy abuse of Postgres’s own features:

  1. Backup to a foreign database. The attacker points /backup at an attacker-controlled PostgreSQL server and dumps its contents onto the Splunk filesystem.
  2. Restore with a stolen passfile. The /restore endpoint accepts a passfile argument. Pointing it at Splunk’s own /opt/splunk/var/packages/data/postgres/.pgpass — which holds the password for the postgres_admin user — lets the attacker authenticate to the local database.
  3. Execute attacker SQL. SQL embedded in the malicious dump runs during restore. The attacker defines a function using lo_export (Postgres’s large-object-to-file routine) to write arbitrary content anywhere the Splunk user can write.
  4. Escalate to RCE. With an arbitrary file write, the attacker overwrites a Python script Splunk executes on its own — for example /opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py — and waits for Splunk to run the payload.

No memory corruption, no exploit mitigations to defeat — just app-layer auth that was never there, plus a database that trusts whoever holds its passfile.

Impact assessment

Affected builds are Splunk Enterprise below 10.2.4 and below 10.0.7. Two deployment details decide your blast radius. The sidecar is not installed or enabled by default on on-prem Windows, which narrows exposure there. But Splunk Enterprise images on AWS ship with the sidecar installed and enabled out of the box — those are exposed by default. Splunk Cloud is not affected, because it does not use Postgres sidecars.

The reason this rates a tonight response isn’t just the 9.8. Splunk is the aggregation point: it ingests logs, often holds forwarder and integration credentials, and sits with broad network visibility. Pre-auth RCE on that host is a near-ideal foothold for an intruder who wants both to see everything and to tamper with the evidence afterward.

Mitigation — what to do right now

Upgrade to a fixed release: 10.0.7, 10.2.4, or 10.4.0 (or later). There is no configuration toggle in the advisory that substitutes for patching.

BranchAffectedFixed
10.0.x10.0.0–10.0.610.0.7
10.2.x10.2.0–10.2.310.2.4
10.4.xnot affected10.4.0

Until you can patch, restrict network access to the Splunk web/management ports to trusted management networks only — the entire chain depends on reaching the proxied sidecar endpoints. Audit AWS-hosted instances first, since they are exposed by default. After patching, rotate the postgres_admin credential and review the splunk_secure_gateway app scripts and recent file writes under /opt/splunk for tampering.

Sources