A critical pre-authentication remote code execution (RCE) vulnerability in Splunk Enterprise has been disclosed, carrying a near-perfect CVSS score of 9.8.
Tracked as CVE-2026-20253, the flaw was published by Splunk on June 10, 2026, and affects the PostgreSQL Sidecar Service introduced in Splunk version 10.
The root cause of CVE-2026-20253 lies in the PostgreSQL Sidecar Service’s HTTP API endpoints specifically /v1/postgres/recovery/backup and /v1/postgres/recovery/restore which lack any authentication controls.
Splunk Enterprise Pre-Auth RCE
These internal endpoints are accessible through Splunk’s main web application via a proxy mechanism, meaning any network-reachable attacker can invoke them without valid credentials.
The exposure is most severe on Splunk Enterprise hosted on AWS, where the PostgreSQL Sidecar Service is installed and enabled by default, making those instances vulnerable out of the box.
On-premises Windows deployments are less immediately affected, as the service is either not installed or not enabled by default.
WatchTowr discovered that the /backup endpoint passes attacker-controlled parameters directly to pg_dump, including the backupFile path and database name. Path traversal in the backupFile parameter immediately enables arbitrary file creation and truncation anywhere on the filesystem.
The more critical discovery came from PostgreSQL’s own design: the database parameter accepts a full libpq connection string, and any parameters defined within it override hardcoded command-line arguments.
This allowed researchers to inject hostaddr and redirect pg_dump to connect to an attacker-controlled PostgreSQL server instead of localhost. With the ability to redirect pg_dump to an external host, researchers then turned to the /restore endpoint, which passes input to pg_restore.
A plaintext .pgpass file discovered at /opt/splunk/var/packages/data/postgres/.pgpass exposed the local postgres_admin credentials.
By injecting a passfile connection string parameter pointing to this file, attackers can fully authenticate to Splunk’s local PostgreSQL instance and restore an attacker-controlled database dump, executing arbitrary SQL in the process.
The malicious dump leverages PostgreSQL’s lo_export function to write attacker-controlled content to any path on the filesystem, achieving a fully controlled arbitrary file write as the splunk user.
With an arbitrary file write in hand, reaching RCE required only one final step. Researchers identified that Splunk regularly executes the Python script /opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py.
Overwriting this file with a malicious payload delivered via the lo_export-based write primitive resulted in code execution as the splunk user the next time Splunk invoked the script, completing the pre-authentication RCE chain.
Affected Versions and Mitigation
CVE-2026-20253 affects Splunk Enterprise versions 10.x and above, as the PostgreSQL Sidecar component was introduced in version 10.
Organizations running Splunk Enterprise particularly AWS-hosted deployments should apply Splunk’s patch immediately and audit filesystem access to the PostgreSQL Sidecar service directory.
Security teams should also review .pgpass file exposure and ensure internal Splunk service ports are properly segmented from external interfaces.
watchTowr Labs has released a Detection Artifact Generator (DAG) on GitHub that probes whether the /v1/postgres/recovery/backup endpoint responds without valid credentials, a 400 status code indicates vulnerability, while a 401 confirms the instance is patched or protected.
The vulnerability is a stark reminder that security monitoring platforms are high-value targets, and authentication gaps in internal service APIs can silently undermine an entire enterprise’s security posture.
Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.
