CVE-2026-20253: Splunk Enterprise unauthenticated file write through the Postgres sidecar

What it is

Splunk Enterprise 10 runs a PostgreSQL sidecar next to splunkd. Its API listens only on loopback, but Splunk Web (port 8000) proxies requests to it, and the API does not check authentication. Any user who can reach Splunk Web can call it. Splunk’s advisory describes the impact as creating or truncating arbitrary files (CWE-306).

watchTowr showed that this goes further than file writes. Their chain calls the unauthenticated backup and restore endpoints, points pg_dump at an attacker-controlled database, and uses a PostgreSQL function to write attacker-chosen bytes to disk. Overwriting a Python script that Splunk runs gives code execution as the splunk user.

Splunk’s PSIRT confirmed limited exploitation in June 2026, and CISA added the CVE to KEV on June 18. It is the first Splunk CVE on that list. No public report says who is exploiting it or what they did afterwards. A Splunk server holds credentials and logs from across the network, so a compromise is worth treating seriously.

Am I affected?

You are affected if you run self-managed Splunk Enterprise:

• 10.2.0 to 10.2.3 (fixed in 10.2.4), or
• 10.0.0 to 10.0.6 (fixed in 10.0.7).

Not affected: 10.4 (fixed from 10.4.0), 9.4 and 9.3, and Splunk Cloud Platform.

The sidecar must also be running. Splunk’s advisory does not say how to check this, so these points come from watchTowr and should be confirmed on your own hosts:

• On Splunk Enterprise on AWS, the sidecar is installed and enabled by default, so watchTowr calls it vulnerable out of the box.
• On a manual Windows install, watchTowr found it either not installed or installed but disabled.
• A running sidecar shows as a splunk-postgres process under $SPLUNK_HOME/var/run/supervisor/pkg-run/, listening on 127.0.0.1:5435.
• If $SPLUNK_HOME/etc/system/local/server.conf has [postgres] with disabled = true, the sidecar was turned off on purpose.

Exposure follows from who can reach Splunk Web. Treat any instance reachable from the internet or from broad internal networks as exposed.

What to do

1. Upgrade to 10.4.0, 10.2.4, 10.0.7 or later.

2. If you can’t upgrade tonight, disable the sidecar. Splunk’s workaround is to add this to $SPLUNK_HOME/etc/system/local/server.conf and restart Splunk Enterprise:

[postgres]
disabled = true

Don’t use this if you rely on Edge Processor, OpAmp or SPL2 data pipelines. Disabling PostgreSQL breaks them and can cascade to dependent sidecar processes. Core search, indexing and dashboards are not affected. With the sidecar off, Splunk rates the impact informational.

3. Restrict access to Splunk Web to the people and networks that need it. watchTowr recommends this as a precaution. Don’t leave it open to the internet.

4. If an instance was reachable while vulnerable, check it (below). The vendor says exploitation started in June 2026, and CISA listed the CVE on June 18. If you find signs of compromise:

   • Isolate the host and rebuild it from known-good media. Upgrading does not remove a modified script or a persistent implant.
   • Rotate secrets the host could read: Splunk admin and service accounts, .pgpass credentials, API and HEC tokens, and credentials stored in apps and add-ons such as LDAP bind accounts and cloud keys.
   • Look for lateral movement from the Splunk host.

Detection

Splunk lists no detections, and nobody has published indicators from real attacks. The pointers below come from watchTowr’s research and the Hard2bit write-up. Use them as hunting leads, not as proof either way.

• Requests to the sidecar API through Splunk Web: search web access logs for /v1/postgres/recovery/backup and /v1/postgres/recovery/restore, for example under /en-US/splunkd/__raw/. watchTowr’s check expects a 401 on a patched host and a 400 on a vulnerable one.
• Modified or new files:
  • Python scripts under $SPLUNK_HOME/etc/apps/, in particular splunk_secure_gateway/bin/ssg_enable_modular_input.py, which watchTowr overwrote.
  • New files under $SPLUNK_HOME/var/run/supervisor/pkg-run/ and in /tmp/.
  • Unexpected files in the Splunk Web webroot. watchTowr’s test left watchTowr.txt there.
• Outbound connections from the Splunk host to PostgreSQL servers you don’t recognise.
• Child processes of splunkd that you wouldn’t expect, such as shells or download tools.