Splunk CVE-2026-20253: Unauthenticated RCE in PostgreSQL Sidecar

Any platform engineer who has ever fronted Splunk with an internal load balancer just lost a weekend. CVE-2026-20253 is the kind of disclosure that turns a Friday standup into an emergency change ticket. A PostgreSQL sidecar shipped without authentication, two REST endpoints, and a clean path from unauthenticated network access to remote code execution as the Splunk user.

Splunk, now part of Cisco, dropped the fixes this week. watchTowr Labs followed up Friday with the full exploit chain. There is no in-the-wild exploitation reported yet, but the technical writeup is detailed enough that opportunistic scanning is a matter of days, not months.

What Happened

Splunk released security updates for a critical flaw in Splunk Enterprise tracked as CVE-2026-20253, rated 9.8 on CVSS. As The Hacker News reported, the bug allows unauthenticated file operations and remote code execution through a PostgreSQL sidecar service endpoint that lacks authentication controls.

In Splunk's own words, "an unauthenticated user could create or truncate arbitrary files through a PostgreSQL sidecar service endpoint" on versions below 10.2.4 and 10.0.7. Splunk Enterprise 10.0.0 through 10.0.6 is fixed in 10.0.7. Versions 10.2.0 through 10.2.3 are fixed in 10.2.4. Version 10.4 is not affected. Splunk Cloud is also out of scope because Postgres sidecars are not used in that product.

The technical details came courtesy of watchTowr Labs, whose researchers Piotr Bazydlo and Yordan Ganchev published the chain on Friday. The two vulnerable endpoints, /v1/postgres/recovery/backup and /v1/postgres/recovery/restore, sit exposed without credentials. From there, the attacker connects the backup endpoint to a database they control, pulls the dump onto the Splunk file system, and replays it through restore. The restore step accepts a passfile argument pointing at /opt/splunk/var/packages/data/postgres/.pgpass, which conveniently holds the password for the postgres_admin user.

That gets you SQL execution inside the local PostgreSQL instance. From there, an attacker abuses lo_export to write attacker-controlled content anywhere on disk. The final pivot to RCE is straightforward: overwrite a Python script Splunk executes routinely, in the proof of concept the file /opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py, and wait. No credentials. No user interaction. No CVE chaining required.

Technical Anatomy

The shape of this bug is depressingly familiar. A team builds a microservice with a clean HTTP API for internal orchestration, assumes the network boundary is the auth boundary, and ships. The PostgreSQL sidecar in Splunk Enterprise is exactly that pattern. Backup and restore endpoints designed for internal recovery workflows, exposed on a port reachable by anything that can talk to the Splunk host.

Step one in the chain: the attacker stands up a PostgreSQL instance configured for passwordless authentication, with permissions wide enough to invoke lo_export. Step two: hit /v1/postgres/recovery/backup on the target, pointing it at the attacker's database. Splunk's sidecar happily dumps the remote DB content onto the local file system. Step three: hit /v1/postgres/recovery/restore with the passfile argument pointed at the on-disk .pgpass, which gives the restore process the password for postgres_admin on the local instance.

During restore, the SQL inside that dump executes against the local PostgreSQL. The researchers crafted a dump that defines a function calling lo_export, which extracts a binary large object and writes it as a file. That gives you an arbitrary file write primitive with the privileges of the Splunk PostgreSQL process. As Bazydlo and Ganchev put it, "Once we could restore attacker-controlled SQL into the local PostgreSQL instance, we quickly put together a database dump template that gave us a controlled file write."

The escalation to RCE is the easy part. Splunk Secure Gateway runs Python scripts on its own schedule. Overwrite ssg_enable_modular_input.py, wait for the next invocation, and your payload runs in Splunk's context. The whole chain is mechanical. No memory corruption, no race conditions, no exotic primitives. This is the kind of exploit that gets weaponized in a Metasploit module within the week. Track the entry in the MITRE CVE database for downstream advisories.

Who Gets Burned

Splunk Enterprise sits at the center of detection pipelines for banks, exchanges, iGaming operators, ad networks, and most Fortune 500 SOCs. That is the painful part. The system you trust to tell you when something bad is happening is itself the soft target. From production incidents I've seen, when a logging or observability stack falls, blue teams lose visibility at the exact moment they need it most. Attackers know this. A pre-auth RCE in Splunk is not a credential theft target; it is a "blind the defenders" target.

The 9.8 CVSS score is not marketing. It maps to network attack vector, no privileges, no user interaction, and full impact on confidentiality, integrity, and availability. For a regulated iGaming operator running Splunk as the system of record for player activity, that score translates to a compliance fire drill. Auditors will want to know patch timelines, network exposure of the affected ports, and whether any anomalous file writes occurred in the /opt/splunk/etc/apps/ tree.

Teams running Splunk Cloud get a free pass here. The PostgreSQL sidecars are not used in that product. Everyone on self-hosted Enterprise between 10.0.0 and 10.0.6, or 10.2.0 and 10.2.3, has work to do. Version 10.4 deployments can stand down on this CVE.

My take: the operators who get burned hardest will be the ones who treat Splunk as "internal" infrastructure and never put it behind a real auth proxy or network segmentation policy. Teams I've worked with regularly leave indexer and management ports reachable across flat VLANs because "it's behind the firewall." That is exactly the assumption this CVE punishes. If your Splunk node is reachable from a developer laptop, it is reachable from a phished developer laptop.

Playbook for Security Teams

Patch first, investigate second, refactor third. The uncomfortable read: if you are still running 10.0.x or 10.2.x with the affected sidecar exposed, assume the timeline for opportunistic scanning is days, not weeks. watchTowr's writeup is detailed enough that the exploit work is essentially done.

Actions for this week:

• Upgrade Splunk Enterprise to 10.0.7, 10.2.4, or 10.4 immediately. No staging gate longer than 48 hours for production indexers.
• Audit network exposure of the PostgreSQL sidecar endpoints. The two paths to grep firewall and WAF logs for are /v1/postgres/recovery/backup and /v1/postgres/recovery/restore.
• Hash and monitor the contents of /opt/splunk/etc/apps/splunk_secure_gateway/bin/ and adjacent app directories. Any unexpected modification to ssg_enable_modular_input.py is your indicator of compromise.
• Check for unexpected files written under paths the Splunk user can reach. The bug grants arbitrary file write, not just the one script targeted in the PoC.
• Cross-reference the CISA KEV catalog daily for updates on active exploitation status.

For the next 90 days, the structural fix is segmentation. Splunk indexers and search heads should not be reachable on management ports from general-purpose corporate networks. Put them behind a bastion or service mesh that enforces mTLS. Treat every internal sidecar as a public endpoint by default, because that is how the next bug like this will land.

Key Takeaways

• CVE-2026-20253 is a 9.8 CVSS pre-auth RCE in Splunk Enterprise's PostgreSQL sidecar. Patch to 10.0.7, 10.2.4, or 10.4.
• The exploit chain abuses /v1/postgres/recovery/backup and /v1/postgres/recovery/restore plus lo_export to achieve arbitrary file write, then overwrites a scheduled Python script for code execution.
• Splunk Cloud is not affected. Self-hosted Enterprise users in the affected version ranges are.
• No in-the-wild exploitation reported yet, but watchTowr's public technical detail makes opportunistic scanning likely within days.
• Treat internal sidecar services as untrusted by default. Network position is not authentication, and this CVE is the proof.