Critical Vulnerability Discovered in Splunk Enterprise: Pre-Authentication Remote Code Execution Risk
A significant pre-authentication remote code execution (RCE) vulnerability has been identified in Splunk Enterprise, earning a nearly maximum Common Vulnerability Scoring System (CVSS) score of 9.8. This critical flaw, known as CVE-2026-20253, was disclosed by Splunk on June 10, 2026. It particularly impacts the PostgreSQL Sidecar Service, which was rolled out in version 10 of Splunk.
The crux of the vulnerability lies within the HTTP API endpoints of the PostgreSQL Sidecar Service. Specifically, the endpoints located at /v1/postgres/recovery/backup and /v1/postgres/recovery/restore are devoid of any authentication mechanisms, which makes them accessible to attackers without valid credentials. This situation is especially precarious for instances hosted on Amazon Web Services (AWS), as the PostgreSQL Sidecar Service comes pre-installed and enabled by default. Consequently, these installations are vulnerable right out of the box. Conversely, on-premises Windows deployments are less immediately at risk because the PostgreSQL Sidecar Service is either not installed or not activated by default.
The security research firm WatchTowr has found alarming details regarding how this vulnerability can be exploited. For instance, the /backup endpoint allows attacker-controlled parameters to be passed directly to pg_dump, which includes both the backupFile path and the database name. A notable vulnerability lies in the backupFile parameter, where path traversal can facilitate arbitrary file creation and truncation anywhere on the filesystem.
The design of PostgreSQL enhances the severity of this vulnerability. Specifically, the database parameter accepts a complete libpq connection string, wherein any specifications provided can override hardcoded command-line parameters. This functionality enables attackers to inject a hostaddr, thus redirecting pg_dump to communicate with a PostgreSQL server controlled by the attacker rather than the localhost. After gaining this foothold, attention can be shifted to the /restore endpoint, where input is relayed to pg_restore.
A plaintext .pgpass file located in /opt/splunk/var/packages/data/postgres/.pgpass reveals local postgres_admin credentials. By injecting a passfile connection string parameter that points to this file, an attacker can gain full authentication to Splunk’s local PostgreSQL instance. This access allows for the restoration of a maliciously crafted database dump, thereby executing arbitrary SQL commands in the process.
The attackers can utilize the lo_export function in PostgreSQL, allowing them to write pre-defined content to any path on the system filesystem. This grants them complete control over file writing as the splunk user. With this arbitrary file write capability established, reaching remote code execution hinges on one final maneuver. Researchers have identified that Splunk routinely runs the Python script situated at /opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py. By substituting this script with a malicious payload using the write primitive enabled by lo_export, the next execution of the script will trigger code execution under the splunk user, effectively concluding the pre-authentication RCE exploit chain.
CVE-2026-20253 affects all versions of Splunk Enterprise 10.x and later, as the PostgreSQL Sidecar component was integrated starting with version 10. For organizations relying on Splunk Enterprise, especially those with AWS-hosted deployments, it is imperative to apply the patch provided by Splunk immediately. Furthermore, they should undertake an audit of filesystem access associated with the PostgreSQL Sidecar Service directory.
Security teams are also advised to scrutinize and protect the exposure of the .pgpass file while ensuring that internal service ports of Splunk are properly isolated from external networks. To aid in monitoring this vulnerability threat, WatchTowr Labs has introduced a Detection Artifact Generator (DAG) available on GitHub. This tool allows users to check if the /v1/postgres/recovery/backup endpoint responds without valid credentials. A response indicating a 400 status code would reveal a vulnerability, whereas a 401 status code would suggest that the instance is either patched or otherwise secured.
This alarming vulnerability underscores a crucial lesson: security monitoring platforms themselves are high-value targets. Gaps in authentication for internal service APIs can quietly jeopardize an enterprise’s entire security framework. It serves as a stark reminder for organizations to implement stringent security measures and regularly update their systems to mitigate emerging threats.