Splunk Enterprise CVE-2026-20253: KEV-listed unauthenticated RCE via PostgreSQL sidecar

Splunk disclosed CVE-2026-20253 on June 10, 2026 via advisory SVD-2026-0603 — an unauthenticated arbitrary file create/truncate primitive in the PostgreSQL Sidecar Service of Splunk Enterprise 10. CVSS v3.1 is 9.8 (Critical), mapped to CWE-306 (Missing Authentication for Critical Function). CISA added the CVE to the Known Exploited Vulnerabilities catalog on June 18, set a federal patch deadline of June 21, and reporting at BleepingComputer confirmed Splunk PSIRT's acknowledgment of limited exploitation in the wild the same day. This is the first Splunk vulnerability ever added to KEV.

WatchTowr Labs published a full technical writeup and working exploit on June 12 — two days after the patch dropped — chaining the file write into unauthenticated remote code execution.

What the bug does

The PostgreSQL Sidecar Service introduced in Splunk Enterprise 10 exposes two endpoints under the splunkd management interface (port 8089):

• /services/splunkd/__raw/v1/postgres/recovery/backup
• /services/splunkd/__raw/v1/postgres/recovery/restore

Per the SVD-2026-0603 advisory, those endpoints lack authentication controls. Any network-reachable client can invoke file operations against them without credentials.

WatchTowr's analysis turns the file-write primitive into RCE by abusing PostgreSQL's built-in lo_export() during the restore flow: a crafted backup archive instructs the server to write attacker-controlled content over a Splunk-owned script that the platform executes periodically. The target named in the WatchTowr writeup is /opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py. Once overwritten, the Splunk daemon runs the attacker's payload as the splunk user on its next invocation.

The chain is pre-authentication end-to-end. No Splunk credentials, no Splunk token, no Splunk session.

Affected versions

Per SVD-2026-0603:

• Splunk Enterprise 10.0.0 through 10.0.6 → fixed in 10.0.7
• Splunk Enterprise 10.2.0 through 10.2.3 → fixed in 10.2.4
• Splunk Enterprise 10.4.0 and later → not affected
• Splunk Enterprise 9.4 and earlier → not affected (sidecar service does not exist on those branches)
• Splunk Cloud Platform → not affected (Splunk patched the managed environment ahead of public disclosure)

Splunk's advisory specifically calls out AWS deployments: on AWS, the PostgreSQL Sidecar Service is installed and enabled by default. On-prem installs typically have to enable it explicitly, but operators who turned it on for backup or recovery workflows are equally exposed.

Exploitation status

Three independent confirmations of in-the-wild use:

• Splunk PSIRT, June 18 update to the advisory: "Splunk PSIRT became aware of limited exploitation."
• CISA KEV, June 18 catalog addition — KEV listings require validated evidence of active exploitation.
• WatchTowr Labs technical analysis and working exploit, published June 12, lowering the cost of opportunistic exploitation to near zero from that date forward.

Help Net Security and SecurityWeek frame the timeline as eight days from patch to confirmed exploitation. Splunk has not publicly named victims or attributed the activity to any group; treat ambient framing about specific actors as speculation until upstream says otherwise.

Detection

Splunk's advisory does not ship Sigma, YARA, or Snort rules. The narrow detection surface upstream calls out is HTTP access to the two __raw/v1/postgres/recovery/* endpoints from any source other than your documented backup tooling — and the file-write side, modifications to splunk_secure_gateway/bin/ssg_enable_modular_input.py outside a Splunk upgrade window.

Internet-exposed splunkd management interfaces typically listen on port 8089. Whether you find your population through Shodan, Censys, or your own asset inventory, any Splunk Enterprise 10 host on a 10.0.x or 10.2.x release reachable from untrusted networks is in scope today.

Action checklist

1. Upgrade Splunk Enterprise to 10.0.7, 10.2.4, or 10.4.x on the matching branch. The CISA KEV federal deadline was June 21 — every day past that is a day attackers have a working public exploit and you don't have the patch. Reference: SVD-2026-0603.
2. If you cannot upgrade immediately, disable the PostgreSQL Sidecar Service. Add the override to $SPLUNK_HOME/etc/system/local/server.conf per the Splunk advisory and restart splunkd. Confirm port 8089 no longer answers on /services/splunkd/__raw/v1/postgres/recovery/*.
3. Hunt for compromise on every unpatched host: check write timestamps on /opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py and on every file under splunk_secure_gateway/bin/. Anything modified outside a known Splunk upgrade or app install window is a compromise hypothesis.
4. Pull splunkd_access.log and grep for the two recovery endpoints. Any request from outside your backup tooling on an unpatched host warrants forensic review.
5. Take internet-exposed splunkd off the internet. Port 8089 belongs on the management plane, not the public internet — and that was true before this CVE.
6. Rotate Splunk service account credentials and search-head tokens on any host you treated as possibly compromised. The exploit runs as the splunk user; assume anything that user can read is exfiltrated.

Context

CVE-2026-20253 is the first Splunk CVE ever added to KEV — a milestone less because Splunk has been bug-free historically and more because the platform sits on the management plane where authenticated-only bugs rarely cross the threshold of "validated active exploitation" CISA requires. A pre-authentication file-write that chains cleanly into code execution under the splunk user is exactly the shape of bug that does. The exploitation timeline — patch on day zero, public RCE writeup on day two, KEV listing on day eight — mirrors the cadence we saw in our coverage of Drupal CVE-2026-9082 and the second Cisco SD-WAN Manager zero-day, CVE-2026-20262. The window between patch availability and mass scanning has been shrinking all year; on this one, the WatchTowr writeup compressed it further.

The structural reading is uncomfortable but consistent with the rest of 2026: management-plane software shipped with auth bolted on at the wrong layer keeps producing pre-auth RCEs. The PostgreSQL sidecar trusts the network it lives on, the network trusts splunkd to enforce auth on its behalf, and neither assumption survives contact with an exposed port 8089. If your Splunk management interface is internet-reachable today, the patch is the floor, not the ceiling — pull it behind a bastion before the next sidecar CVE lands.