Splunk Enterprise 10 shipped an unauthenticated database endpoint on port 8000

Splunk Enterprise 10 introduced a PostgreSQL Sidecar Service to support SPL2 data pipelines, Edge Processor, and OpAmp. The service runs on localhost port 5435 and has no HTTP-level authentication. The main Splunk web application, on port 8000, proxies requests to it. An empty credential string gets you through. That is CVE-2026-20253, CVSS 9.8, and it is being exploited in the wild.

Splunk Enterprise 9.4 and earlier are unaffected. The sidecar did not exist before version 10.

What the attack looks like

The entry point is /en-US/splunkd/__raw/v1/postgres/recovery/, reachable on port 8000 without credentials. The Authorization header value Basic Og== (base64 for a bare colon) passes the check.

WatchTowr Labs documented two endpoints that do the work. The backup endpoint accepts a database parameter that feeds into pg_dump without sanitization. The restore endpoint runs pg_restore against whatever you point it at. The chain: create a PostgreSQL database containing a function that calls lo_export, use the backup endpoint to dump it onto the Splunk filesystem, use the restore endpoint to execute the dump and trigger the function, which then writes an arbitrary file to disk. WatchTowr targeted /opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py, a Python script that runs in the Splunk app context. File written, code executed.

The PostgreSQL credentials that authenticate to the database itself are stored at /opt/splunk/var/packages/data/postgres/.pgpass in plaintext. The HTTP proxy layer never consults them.

The timeline

Splunk published the advisory and patched versions on June 10. WatchTowr published the full technical writeup with the attack chain on June 12. Splunk confirmed limited exploitation on June 18. CISA added CVE-2026-20253 to its Known Exploited Vulnerabilities catalog with a June 21 deadline for federal civilian agencies.

Eight days from patch to confirmed exploitation. Six days from WatchTowr’s detailed PoC to active attacks. Shadowserver tracks more than 1,400 exposed Splunk instances reachable on the public internet, the majority in North America.

Why it is designed this way

The sidecar was built on the assumption that localhost is a trust boundary. That assumption is wrong when a front-end application proxies inward without re-authenticating the caller, which is exactly what Splunk’s web layer does. Any network path to port 8000 (the same port your analysts use to log into dashboards) is also a path to the sidecar. The service has its own PostgreSQL authentication; the HTTP proxy layer skips it.

This is not an unusual failure mode. Internal microservices that trust network position instead of authenticating callers are a recurring source of complete-bypass vulnerabilities. What makes this version more pointed is where the sidecar lives: on the platform aggregating security telemetry from your environment. An attacker who gets code execution on a Splunk indexer can read or corrupt the log stream that would detect them.

What to do

The fix is a version upgrade. Splunk released patched versions on June 10:

• Splunk Enterprise 10.2.4 for the 10.2.x branch (from any 10.2.0 through 10.2.3)
• Splunk Enterprise 10.0.7 for the 10.0.x branch (from any 10.0.0 through 10.0.6)
• Splunk Enterprise 10.4.0 for anyone on the current release track

Splunk Cloud Platform is patched by Splunk. No customer action required on that platform.

Per Splunk’s advisory, a workaround exists: add [postgres] with disabled = true to server.conf to shut down the sidecar. The advisory also notes this workaround is incompatible with Edge Processor, OpAmp, and SPL2 data pipelines. Disabling the sidecar breaks those features.

The organizations most invested in Splunk 10, specifically those who adopted SPL2 or Edge Processor, are the ones the workaround does not work for. There is no configuration path to safety for them. The only option is the upgrade.

If you are running Splunk Enterprise 9.4 or earlier, you are not affected.

The accountability note

Splunk introduced the PostgreSQL sidecar as infrastructure for its next-generation data pipeline features. Customers who stayed on Splunk 9.x and declined the SPL2 migration did not get the vulnerability. Customers who upgraded to take advantage of the new pipeline capabilities got an unauthenticated HTTP-accessible database service running alongside their SIEM, and no workaround that preserves those capabilities. That is a bad outcome for the people who moved fastest and trusted the product roadmap most.

The patch window between June 10 and June 18, eight days, is now closed. If your Splunk Enterprise 10.0.x or 10.2.x instance had port 8000 reachable during that window, treat it as potentially compromised rather than just unpatched. The attack chain writes files to the Splunk app directory; checking for unexpected files there is a reasonable first step while the upgrade is scheduled.

PatchDayAlert flags vulnerabilities like this when they hit the KEV catalog and leads with version numbers and patch targets, because those are the two facts that actually change what you do on Monday morning.

Sources

• Splunk Security Advisory SVD-2026-0603 — 2026-06-10
• WatchTowr Labs: CVE-2026-20253 Pre-Auth RCE writeup — 2026-06-12
• SecurityWeek: Splunk Enterprise vulnerability exploited in attacks — 2026-06-18
• BleepingComputer: CISA Splunk Enterprise flaw actively exploited, patch by Sunday — 2026-06-19
• CISA Known Exploited Vulnerabilities Catalog — ongoing
• NVD CVE-2026-20253 — 2026-06-10