Splunk has shipped emergency updates for Splunk Enterprise to close CVE-2026-20253, a critical pre-authentication remote code execution chain in the new PostgreSQL sidecar service that ships with version 10 of the data platform. The flaw carries a CVSS score of 9.8 out of 10 and is enabled by default in Splunk Enterprise on AWS, putting cloud deployments at immediate risk.
Unauthenticated PostgreSQL Sidecar Endpoint
In its advisory, Splunk warns that on Splunk Enterprise versions below 10.0.7 and 10.2.4 "an unauthenticated user could create or truncate arbitrary files through a PostgreSQL sidecar service endpoint" because the endpoint "lacks authentication controls". The fixes land in Splunk Enterprise 10.0.7 and 10.2.4, while Splunk Enterprise 10.4 and Splunk Cloud Platform are unaffected because Cisco-owned Splunk does not run Postgres sidecars in those environments.
The risk profile is sharper than the advisory suggests. The PostgreSQL sidecar is dormant on Windows on-prem installations, but Splunk Enterprise on AWS bundles and enables it by default, meaning a freshly spun-up AWS instance is exploitable out of the box.
watchTowr Labs Turns The Bug Into Pre-Auth RCE
On June 12, security researchers Piotr Bazydlo and Yordan Ganchev at watchTowr Labs published a deep technical writeup that chains the file-write primitive into full remote code execution as the splunk user. The researchers found that the sidecar accepts any value in the HTTP Authorization header and forwards it to pg_dump, which is invoked with a hard-coded -h localhost argument.
That looks safe — until you remember that PostgreSQL connection strings can override command-line options. By smuggling a hostaddr parameter into the database field, the watchTowr team forced Splunk to pg_dump against an attacker-controlled remote Postgres instance, then used the matching /v1/postgres/recovery/restore endpoint together with a path to Splunk's local .pgpass file to load a malicious dump into the on-host PostgreSQL service. A small plpgsql function calling lo_export writes arbitrary content to disk; overwriting the frequently executed ssg_enable_modular_input.py script in /opt/splunk/etc/apps/splunk_secure_gateway/bin yields code execution.
Patch Now, Especially In AWS
watchTowr has released a public detection artefact generator on GitHub that flags vulnerable hosts based on whether the /v1/postgres/recovery/backup endpoint accepts arbitrary credentials. There is no confirmed in-the-wild exploitation yet, but the combination of a 9.8 CVSS rating, a published exploit chain and default-on AWS deployments is the playbook attackers usually run against SIEM stacks, which themselves sit at the heart of enterprise security operations.
For Splunk, the disclosure lands days after CISA added an actively exploited Oracle PeopleSoft zero-day to the KEV catalog and as enterprise teams race to ship a Chrome V8 patch in the same week. Splunk admins should move to 10.0.7 or 10.2.4 immediately and audit AWS-hosted Splunk Enterprise systems for unexplained files in the sidecar or webroot.
Reporting based on coverage from Splunk, watchTowr Labs and The Hacker News.