A critical vulnerability in Splunk Enterprise elevates what was initially reported as an arbitrary file-creation flaw to unauthenticated Remote Code Execution (RCE).
Tracked as CVE-2026-20253, the vulnerability carries a maximum CVSS score of 9.8. It specifically impacts the PostgreSQL Sidecar Service introduced in Splunk version 10.
According to Watchtowr, the sidecar service is not installed or enabled by default on on-premises Windows deployments; Splunk Enterprise instances hosted on AWS are installed and enabled out of the box.
Critical Splunk Enterprise Flaw
The root of CVE-2026-20253 lies in the PostgreSQL Sidecar Service’s API, which listens locally on port 5435.
Attackers can reach this local service remotely because the main Splunk web application, listening on port 8000, proxies requests directly to the internal API. Furthermore, the sidecar service completely lacks authentication controls.
When a user interacts with the /v1/postgres/recovery/backup or /restore endpoints, the API accepts any credentials provided in the HTTP authorization header.
It then blindly forwards the supplied username to the underlying pg_dump or pg_restore utilities via the command-line arguments.
This architectural oversight shifts the burden of authentication entirely onto the local PostgreSQL database, allowing threat actors to interact with its backup and recovery mechanisms freely.
Researchers at watchTowr Labs discovered that the API endpoints allow attackers to inject arbitrary connection string parameters into the database argument.
By overriding the default localhost connection using the hostaddr parameter, an attacker can force the Splunk instance to connect to an external, attacker-controlled database.
To achieve full Remote Code Execution, threat actors can execute a precise chain of operations against the vulnerable endpoints.
First, they can exfiltrate valid local database credentials stored in plaintext within the /opt/splunk/var/packages/data/postgres/.pgpass file.
Next, they can force Splunk to dump a malicious remote database to the local file system via the backup endpoint.
Attackers can then abuse the restore endpoint by passing the valid local credentials via the passfile parameter to load the malicious database dump into the local PostgreSQL instance.
This allows them to trigger an embedded SQL function that uses lo_export to write attacker-controlled content directly to the Splunk file system.
Finally, they can overwrite a frequently executed internal script, such as ssg_enable_modular_input.py, with a malicious Python payload to execute arbitrary shell commands.
Affected Versions and Mitigation
The transition from a simple file-truncation bug to full RCE highlights the severe risk posed by CVE-2026-20253.
Because the exploitation process requires no authentication and targets an endpoint accessible via the primary web application proxy, internet-facing Splunk instances, particularly those deployed on AWS, are highly vulnerable to immediate compromise.
Administrators are urged to review their Splunk Enterprise architecture to determine if the PostgreSQL Sidecar Service is active in their environment.
Security teams can leverage the Detection Artifact Generator provided by watchTowr to safely test whether their instances are vulnerable to unauthenticated API access.
Restricting network access to the Splunk web interface and monitoring for anomalous file modifications within the /opt/splunk/ directory is a critical step before patching can be fully implemented.
Follow us on Google News , LinkedIn and X to Get More Instant Updates. Set Cyberpress as a Preferred Source in Google.
.){kind=link}