A critical vulnerability chain in Splunk Enterprise has been disclosed, enabling unauthenticated attackers to achieve remote code execution (RCE) through a misconfigured PostgreSQL sidecar service.
Tracked as CVE-2026-20253, the flaw has a CVSS score of 9.8 and affects Splunk Enterprise 10 and later.
The issue originates from the PostgreSQL Sidecar Service, an internal component introduced in newer Splunk versions.
While this service is not always enabled in on-premise deployments, it is active by default in Splunk Enterprise on AWS, making cloud deployments particularly exposed out of the box.
Splunk Enterprise Pre-Auth RCE Chain Exposes
According to watchTowr Labs, the vulnerable service listens on localhost but can be accessed externally through Splunk’s main web interface.
Attackers can send crafted HTTP requests to internal API endpoints such as “/v1/postgres/recovery/backup” and “/restore” via the Splunk web service running on port 8000.
The core problem lies in the lack of authentication controls. The API accepts any credentials, including empty values, and forwards them to backend PostgreSQL utilities like pg_dump and pg_restore.
Because these tools are executed without enforcing proper authentication checks, attackers can trigger database operations without valid access.
watchTowr Labs said the vulnerability appears limited to arbitrary file creation and truncation. By manipulating the “backupFile” parameter, attackers can write files to arbitrary locations on the system using directory traversal techniques.
However, researchers discovered a more severe impact by chaining multiple behaviors.
By injecting a PostgreSQL connection string into the “database” parameter, attackers can override default connection settings and force Splunk to connect to an attacker-controlled database. This allows malicious database content to be written to the Splunk filesystem.
watchTowr found that Splunk’s restore feature can use credentials stored in a local .pgpass file, enabling attackers to abuse exposed database credentials during restore operations.
By leveraging this file, attackers can authenticate to the internal PostgreSQL instance and execute arbitrary SQL during the restore process.
Researchers demonstrated that specially crafted SQL payloads can write attacker-controlled files to disk using PostgreSQL large object export functions. This primitive enables full arbitrary file write access under the Splunk user.
With file write access, achieving RCE becomes straightforward. In the proof-of-concept, attackers overwrote a legitimate Splunk Python script that is executed during normal operations.
This allowed them to execute system commands and confirm code execution on the target system.
The vulnerability highlights how internal services exposed through proxy mechanisms can break security assumptions, especially when authentication is inconsistently enforced.
Even services bound to localhost can become remotely reachable through application-layer routing. Splunk has released an advisory and urges users to update affected versions immediately.
Organizations using Splunk Enterprise on AWS should prioritize patching, as the vulnerable component is enabled by default.
The research from watchTowr advised to monitor access to internal API endpoints, restrict unnecessary exposure, and review file integrity for critical Splunk components.
Detection tools developed by researchers can help identify vulnerable systems by testing access-control behavior.
This vulnerability demonstrates how seemingly limited flaws, such as arbitrary file writes, can evolve into full system compromise when combined with design weaknesses and credential exposure.
Follow us on Google News, LinkedIn, and X to Get More Instant Updates.
