CVE-2026-20253: Splunk Enterprise Unauthenticated RCE, CVSS 9.8

This week in our InSEKurity of the Week series: a critical, unauthenticated remote code execution chain in Splunk Enterprise — the data platform and SIEM that sits at the heart of countless Security Operations Centers, ingesting the very logs defenders rely on to catch attackers. Tracked as CVE-2026-20253 and scored CVSS 9.8 (Critical), the flaw lives in a PostgreSQL “sidecar” service bundled with newer Splunk releases. Two HTTP endpoints meant for database backup and restore ship without any authentication, letting a remote attacker create and overwrite arbitrary files on the server — a primitive that researchers turned into full remote code execution running as the Splunk service account. This is not theoretical: watchTowr Labs published a working exploit, Splunk confirmed limited in-the-wild exploitation, and CISA added it to the Known Exploited Vulnerabilities (KEV) catalog with a mandatory federal deadline — making it the first Splunk vulnerability ever to land in KEV. If you run Splunk Enterprise 10.0 or 10.2 on-premises, this one belongs at the very top of your patch queue.

🚨 Summary

CVE ID: CVE-2026-20253
CVSS Score: 9.8 (Critical)
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CWE: CWE-306 (Missing Authentication for Critical Function)
Affected Software: Splunk Enterprise (on-premises) — the bundled PostgreSQL sidecar service used by Edge Processor, OpAmp, and SPL2 data pipelines
Attack Vector: Network (remote, unauthenticated) — crafted HTTP POST requests to the PostgreSQL recovery backup / restore endpoints
Authentication Required: None
User Interaction: None
Impact: Unauthenticated arbitrary file creation/truncation, chained into remote code execution as the Splunk user
Patch Status: ✅ Fixed in Splunk Enterprise 10.0.7, 10.2.4, and 10.4.0+
Published: June 2026 (Splunk advisory SVD-2026-0603)
Exploitation Status: Actively exploited in the wild — public PoC from watchTowr Labs; Splunk PSIRT confirmed limited exploitation
CISA KEV: ✅ Listed (added June 18, 2026; FCEB remediation due June 21, 2026) — the first Splunk CVE ever added

🛡️ What is Splunk Enterprise?

Splunk Enterprise is one of the most widely deployed machine-data and Security Information and Event Management (SIEM) platforms in the world. It ingests, indexes, and searches enormous volumes of logs, metrics, and events from across an organization’s infrastructure — servers, network devices, applications, cloud services — and turns them into searchable, alertable, dashboardable intelligence. In security operations specifically, Splunk is frequently the central nervous system of the SOC: the place analysts pivot, hunt, and investigate.

Newer Splunk Enterprise releases (the 10.x line) bundle a PostgreSQL “sidecar” service — a local database used internally by features such as Edge Processor, OpAmp, and SPL2 data pipelines. To support disaster recovery, this sidecar exposes HTTP endpoints that can back up and restore the PostgreSQL data. The bitter irony of CVE-2026-20253 is hard to miss: the platform organizations buy to detect attackers became an unauthenticated entry point for them. And because Splunk servers are trusted, log-rich, credential-rich systems wired into the entire environment, a foothold here is a foothold almost everywhere.

Typical Use Cases

Security monitoring & SIEM: centralized log collection, correlation, alerting, and threat hunting in the SOC.
IT operations & observability: infrastructure and application monitoring, troubleshooting, and performance analysis.
Compliance & audit: long-term log retention and reporting for regulatory requirements.
Business analytics: turning machine data into operational and business dashboards.
Data pipelines: Edge Processor, OpAmp, and SPL2 routing and transforming data in motion — the features backed by the vulnerable PostgreSQL sidecar.

Because Splunk is deployed deep inside enterprise networks and frequently holds privileged data and credentials, an unauthenticated RCE in its bundled services is about as serious as it gets.

🔍 Technical Analysis

Vulnerability Description

CVE-2026-20253 is a Missing Authentication for Critical Function flaw (CWE-306). Splunk’s bundled PostgreSQL sidecar service exposes two recovery endpoints — a backup endpoint and a restore endpoint — that perform privileged file operations without enforcing any authentication. Any attacker who can reach the service over the network can invoke them directly:

/v1/postgres/recovery/backup
/v1/postgres/recovery/restore

In practice these are reachable through Splunk’s splunkd raw proxy (for example under a /.../splunkd/__raw/v1/postgres/recovery/... path). The backup endpoint accepts an attacker-controlled backupFile path and creates or truncates a file at that location — including via directory traversal outside the intended backup directory. The restore endpoint lets the attacker control the PostgreSQL connection parameters and write arbitrary content to a chosen file. Together, these give an unauthenticated attacker a clean arbitrary file write/overwrite primitive on the Splunk host.

Root Cause Analysis

Independent analysis (watchTowr Labs, by researchers Piotr Bazydło and Yordan Ganchev) traced the flaw to the sidecar’s missing trust boundary. The decisive details:

Critical functions with no authentication: the PostgreSQL recovery backup and restore endpoints execute privileged file operations but never check that the caller is authenticated — the textbook CWE-306 pattern.
Attacker-controlled file path: the backup endpoint takes a backupFile parameter and writes/truncates exactly that path, with no canonicalization to confine it to a safe directory — so ../../../../ traversal reaches anywhere the Splunk process can write.
Attacker-controlled database connection: the restore endpoint lets the caller specify the PostgreSQL connection string (including parameters such as passfile), so the attacker dictates what content is written and where.
Write primitive becomes code execution: by overwriting a script that Splunk itself later executes — for example a Python modular-input helper inside the splunk_secure_gateway app — the attacker’s content runs as the Splunk service account, converting file-write into RCE.
Exposed by a bundled feature: the sidecar exists to support Edge Processor / OpAmp / SPL2 pipelines, so the vulnerable surface is present even where administrators never consciously “enabled PostgreSQL.”
Network-reachable, pre-authentication: the whole chain works remotely with no credentials and no user interaction.

Attack Vector

To weaponize the flaw, an attacker reaches the unauthenticated recovery endpoints and chains a file create with a content write into a Splunk-executed script. The snippets below are illustrative only — they show the shape of the attack, not a turnkey exploit:

# Step 1: Discover internet-facing or network-reachable Splunk instances.
# Splunk Web typically listens on TCP/8000 and splunkd management on TCP/8089.
nmap -sT -p 8000,8089 --open -oG splunk-candidates.gnmap 203.0.113.0/24

# Step 2: Confirm the unauthenticated PostgreSQL recovery endpoint answers
# WITHOUT credentials -- a vulnerable host responds to the backup endpoint.
curl -sk -o /dev/null -w "backup endpoint status: %{http_code}\n" \
    -X POST "https://<splunk-host>:8000/en-US/splunkd/__raw/v1/postgres/recovery/backup" \
    -H "Content-Type: application/json" \
    -d '{"database":"search_metadata","backupFile":"/tmp/probe"}'

# Step 3 (ILLUSTRATIVE): arbitrary file creation/truncation via path traversal.
POST /en-US/splunkd/__raw/v1/postgres/recovery/backup HTTP/1.1
Host: <splunk-host>:8000
Content-Type: application/json

{"database":"search_metadata","backupFile":"../../../../../../../../tmp/poc"}

# Step 4 (ILLUSTRATIVE): write attacker-controlled content via the restore
# endpoint by controlling the PostgreSQL connection parameters. Overwriting a
# script Splunk later runs (e.g. a splunk_secure_gateway Python helper) yields
# code execution as the Splunk user. This does NOT implement CVE-2026-20253.
POST /en-US/splunkd/__raw/v1/postgres/recovery/restore HTTP/1.1
Host: <splunk-host>:8000
Content-Type: application/json

{"database":"dbname=template1 passfile=/opt/splunk/var/packages/data/postgres/.pgpass","backupFile":"/tmp/poc"}

A simplified view of the attack chain:

Attacker                                          Victim (Splunk Enterprise + PostgreSQL sidecar)
   |                                                            |
   |  POST /v1/postgres/recovery/backup (no auth)               |
   |  backupFile = ../../../tmp/poc                             |
   |----------------------------------------------------------->|  file CREATED / TRUNCATED
   |                                                            |  (CWE-306: no auth check)
   |                                                            |
   |  POST /v1/postgres/recovery/restore (no auth)              |
   |  attacker-controlled connection + content                  |
   |----------------------------------------------------------->|  ARBITRARY content written
   |                                                            |  to attacker-chosen path
   |                                                            |
   |  overwrite a Splunk-executed Python script                 |
   |----------------------------------------------------------->|  script runs as SPLUNK user
   |                                                            |
   |<------------------ code execution ------------------------ |  full host compromise
   v                                                            v

The flow above is illustrative only — it does not implement CVE-2026-20253. The actual exploit abuses two unauthenticated PostgreSQL recovery endpoints to obtain an arbitrary file write, then overwrites a script Splunk subsequently executes to gain remote code execution.

Exploitation in the Wild

June 12-13, 2026 — watchTowr Labs publishes a detailed technical write-up and working proof-of-concept exploit, sharply lowering the barrier to exploitation.
June 18, 2026 — The Splunk PSIRT confirms limited in-the-wild exploitation of CVE-2026-20253 and updates its advisory.
June 18, 2026 — CISA adds CVE-2026-20253 to the KEV catalog the same day, signalling confirmed real-world abuse.
Ongoing — With a public PoC and KEV listing, opportunistic mass-scanning for exposed Splunk recovery endpoints is expected; observed exploitation includes benign “marker” files (e.g. a dropped watchTowr.txt) as well as malicious follow-on activity.

Post-Exploitation Impact

Code execution as the Splunk service account: the attacker runs commands on the Splunk host with the privileges of the Splunk process.
Compromise of the SIEM itself: control of the very platform meant to detect attacks lets an intruder read, alter, or delete security telemetry and blind the SOC.
Credential and data theft: Splunk holds ingested logs, API tokens, and integration credentials — prime material for escalation and lateral movement.
Lateral movement: Splunk is wired into much of the environment (forwarders, integrations, cloud connectors), giving the attacker many pivot paths.
Persistence: rogue apps, modular inputs, scheduled searches, or new accounts let the attacker return after the initial session.
Tampering with evidence: an attacker controlling the log platform can erase their own tracks across the whole estate.

⚠️ Impact Assessment

Immediate Impact

Unauthenticated, network-reachable RCE: no credentials and no user interaction — only network access to the Splunk service.
High-value, ubiquitous target: Splunk Enterprise is a flagship SIEM/observability platform across enterprises and governments.
Active exploitation with a public PoC: watchTowr’s working exploit plus confirmed in-the-wild abuse means the window to patch safely is gone.
CISA KEV listed: the first-ever Splunk CVE in KEV, with a mandatory federal remediation deadline — a strong signal of serious exploitation.
The detector becomes the entry point: compromising the SIEM undermines the organization’s ability to even notice the breach.

Affected Versions

Branch	Status	Notes
10.2.0 — 10.2.3	Affected	Upgrade to 10.2.4 or later
10.0.0 — 10.0.6	Affected	Upgrade to 10.0.7 or later
10.2.4+	Fixed	Contains the fix
10.0.7+	Fixed	Contains the fix
10.4.0+	Not affected	Sidecar not vulnerable
9.4 and earlier	Not affected	Predate the PostgreSQL sidecar
Splunk Cloud Platform	Not affected	Managed by Splunk

Splunk advisory SVD-2026-0603 is the authoritative source for exact fixed builds. Always cross-reference it before deploying, and confirm the running version of every on-premises instance.

Affected Environments

On-premises Splunk Enterprise 10.0.x / 10.2.x deployments: the vulnerable sidecar ships with these releases.
Instances using Edge Processor, OpAmp, or SPL2 pipelines: these features rely on the PostgreSQL sidecar — but the surface can be present regardless.
Network-reachable Splunk Web / splunkd: anything an attacker can reach over the network (internet-facing instances are at greatest risk).
SOC and core monitoring infrastructure: the systems whose compromise hurts the most.
Any environment that has not yet upgraded to 10.0.7 / 10.2.4 / 10.4.0+.

Attacker Profiles

Opportunistic scanners: with a public PoC and KEV listing, exposed Splunk instances will be swept en masse.
Ransomware affiliates & initial-access brokers: RCE on a high-value, deeply integrated server is premium access.
APT groups: control of the SIEM enables stealthy, long-dwell espionage and evidence tampering.
Insiders / pivoting attackers: anyone already on the network can trivially turn reachability into full host compromise.

🛡️ Mitigation Strategies

Immediate Actions (Priority 1) ⚡

Upgrade every affected Splunk Enterprise instance immediately. This is the only complete fix:

# Identify the running version on each instance.
/opt/splunk/bin/splunk version

# Upgrade to a fixed release per Splunk advisory SVD-2026-0603:
#   10.2.x  -> 10.2.4 or later
#   10.0.x  -> 10.0.7 or later
#   (10.4.0+ is not affected)
# Follow Splunk's standard upgrade procedure and validate after upgrade.

If you cannot patch immediately, disable the PostgreSQL sidecar via server.conf to remove the vulnerable endpoints. Note this disables Edge Processor, OpAmp, and SPL2 data pipelines, so validate the impact first:
```
# $SPLUNK_HOME/etc/system/local/server.conf
[postgres]
disabled = true
```
```
# Apply and restart Splunk for the change to take effect.
/opt/splunk/bin/splunk restart
```

Restrict network access to Splunk Web (TCP/8000) and splunkd management (TCP/8089) so the recovery endpoints are unreachable from untrusted networks:

# Confirm whether the unauthenticated backup endpoint responds. A patched or
# mitigated host should NOT return a success/2xx without authentication.
curl -sk -o /dev/null -w "status: %{http_code}\n" \
    -X POST "https://<splunk-host>:8000/en-US/splunkd/__raw/v1/postgres/recovery/backup" \
    -H "Content-Type: application/json" -d '{"database":"x","backupFile":"/tmp/probe"}'

# Splunk management/web ports should never be exposed to the public internet.
# Place them behind VPN/allow-lists and front-end controls.

Hunt for prior compromise. Because a public PoC and active exploitation predate many patch windows, assume possible breach and investigate:

# Look for unexpected or recently-modified files dropped via the write
# primitive (common staging locations and the splunk_secure_gateway app).
find /tmp /opt/splunk/var/run -type f -newermt "2026-06-10" 2>/dev/null
ls -la /opt/splunk/share/splunk/search_mrsparkle/exposed/watchTowr.txt 2>/dev/null
find /opt/splunk/etc/apps/splunk_secure_gateway/bin -name "*.py" \
    -newermt "2026-06-10" 2>/dev/null

Detection Measures 🔍

# Build detections around:
#   - HTTP POSTs to /v1/postgres/recovery/backup or /restore, especially
#     unauthenticated requests or requests containing ".." path traversal
#     or absolute paths in the "backupFile" parameter.
#   - Restore requests whose "database" value carries unusual connection
#     parameters (e.g. passfile=, dbname=template1).
#   - Creation/modification of Python scripts inside splunk_secure_gateway,
#     or new files under /tmp and /opt/splunk/var/run.
#   - Unexpected child processes spawned by the Splunk service account.
#   - Unusual outbound PostgreSQL connections from the Splunk host.

Web/proxy-side hunting:

# Search web access logs for requests to the PostgreSQL recovery endpoints.
grep -E "/v1/postgres/recovery/(backup|restore)" /opt/splunk/var/log/splunk/*access*.log \
    | grep -E "POST"

# Flag requests with path traversal in the body/parameters.
grep -E "/v1/postgres/recovery/" /opt/splunk/var/log/splunk/*access*.log \
    | grep -F ".."

Deploy IDS/IPS and WAF signatures for the recovery endpoints as they become available, and ingest published IoCs.
Watch for the known marker artifact (a dropped watchTowr.txt) as a quick-and-dirty exposure check, but do not rely on it as the only indicator.

Long-term Security Improvements

Patch tier-0 monitoring fast: treat the SIEM with the same critical-patch SLA as any internet-facing security appliance — it is a crown-jewel system.
Minimize exposed surface: keep Splunk Web/splunkd off the public internet; reach them via VPN, bastions, and allow-lists.
Disable unused bundled features: if Edge Processor / OpAmp / SPL2 pipelines are not used, the PostgreSQL sidecar can stay disabled.
Segment and monitor the SIEM: a server this trusted and integrated deserves tight network segmentation and its own alerting.
Assume-breach for KEV-listed bugs: when a public PoC predates your patch, patch and hunt — don’t assume a clean state.
Inventory continuously: know every Splunk instance, its version, and its exposure — you cannot patch what you cannot see.

🎯 Why is this Critical?

Unauthenticated remote code execution: no credentials, no user interaction — just network reach to a vulnerable Splunk instance.
Active exploitation with a public PoC: watchTowr’s working exploit is out and Splunk confirmed in-the-wild abuse.
First Splunk CVE ever in CISA KEV: a mandatory federal deadline underscores how serious this is.
The detector becomes the door: compromising the SIEM both grants deep access and blinds defenders.
Ubiquitous, high-value target: Splunk Enterprise anchors SOCs and IT operations across enterprises and governments worldwide.
Credential- and data-rich host: Splunk holds logs, tokens, and integration secrets that fuel further compromise.
A clean patch and a clean workaround exist: upgrading fixes it, and disabling the sidecar removes the surface — there is no excuse to leave it exposed.

🚀 Timeline and Disclosure

June 2026 — Splunk publishes advisory SVD-2026-0603 for CVE-2026-20253 and ships fixed builds (10.0.7, 10.2.4, 10.4.0+).
June 12-13, 2026 — watchTowr Labs (Piotr Bazydło, Yordan Ganchev) releases a technical analysis and working proof-of-concept exploit.
June 18, 2026 — The Splunk PSIRT confirms limited in-the-wild exploitation; CISA adds CVE-2026-20253 to the KEV catalog — the first Splunk vulnerability ever listed.
June 21, 2026 — CISA’s mandatory FCEB remediation deadline for federal agencies.

🔗 Resources and References

CVE: CVE-2026-20253
NVD: NVD — CVE-2026-20253
Splunk Advisory: SVD-2026-0603 — Unauthenticated Arbitrary File Creation and Truncation in a PostgreSQL Sidecar Service Endpoint
CWE: CWE-306: Missing Authentication for Critical Function
CISA KEV Catalog: Known Exploited Vulnerabilities

💼 SEKurity Supports You

CVE-2026-20253 is a sharp reminder that your security tooling is part of your attack surface — not an exception to it. The platform many organizations buy specifically to catch intruders shipped a bundled database service with two unauthenticated endpoints, and researchers turned a humble “create a backup file” feature into full remote code execution on the SOC’s most trusted server. Worse, an attacker who owns the SIEM can quietly delete the very evidence that would have caught them. We help organizations find the forgotten, optional, and bundled services quietly listening on critical systems, validate that internet-facing and tier-0 infrastructure is genuinely patched and segmented, and stress-test whether an attacker who compromised your monitoring stack would be detected — or whether they would simply turn off the lights. Our infrastructure and Red Team engagements map exactly these high-trust blind spots before someone with a working exploit finds them first.

Our Services

Penetration Testing: Web applications, mobile apps (Android & iOS), SAP systems, Active Directory
Large-Scale Attacks: Perimeter testing, IT infrastructure testing, Red Team engagements
Security Awareness: Phishing campaigns, hacking demonstrations

Act now — before attackers do.

Contact:

🌐 Website: www.sekurity.de

📧 Inquiries: www.sekurity.de/kontakt

📱 LinkedIn: SEKurity GmbH

Your SEKurity Team — Your Trusted Adversaries

The security of your monitoring infrastructure is our drive.

InSEKurity of the Week (CW25/2026): Splunk Enterprise Unauthenticated RCE via PostgreSQL Sidecar (CVE-2026-20253)