Splunk Enterprise Critical RCE Chain (CVE-2023-46214, CVE-2023-46215) Exposes Data

Key Takeaways

• A critical vulnerability chain (CVE-2026-20253) in Splunk Enterprise allows unauthenticated remote code execution.
• The flaw stems from a misconfigured PostgreSQL Sidecar Service, default in Splunk Enterprise on AWS.
• Attackers can exploit this by chaining arbitrary file write capabilities with SQL injection to achieve full system compromise.
• Splunk has released patches, and users are urged to update immediately, especially those running cloud deployments.

Unauthenticated RCE Puts Splunk Enterprise Data at Risk

Cybersecurity researchers have uncovered a critical vulnerability chain affecting Splunk Enterprise that could allow unauthenticated attackers to execute arbitrary code remotely. The exploit, designated CVE-2026-20253, carries a severe CVSS score of 9.8 and impacts Splunk Enterprise versions 10 and newer.

The root cause of this security lapse lies within a misconfigured PostgreSQL Sidecar Service, an internal component integrated into recent Splunk iterations. While this service might not always be active in on-premise deployments, it is enabled by default in Splunk Enterprise instances hosted on AWS, making cloud environments particularly susceptible straight out of the box.

Exploitation Chain Leverages Internal API and PostgreSQL Flaws

According to findings from watchTowr Labs, the vulnerable PostgreSQL Sidecar Service, though designed to listen on localhost, becomes externally accessible via Splunk’s primary web interface. Attackers can leverage this by sending specially crafted HTTP requests to internal API endpoints, such as “/v1/postgres/recovery/backup” and “/restore,” through the Splunk web service operating on port 8000.

The core issue is a critical lack of authentication. The API indiscriminately accepts any credentials, including empty strings, and forwards them to backend PostgreSQL utilities like pg_dump and pg_restore. This absence of proper authentication checks means attackers can initiate database operations without needing valid access.

Initially, watchTowr Labs observed that the vulnerability appeared limited to arbitrary file creation and truncation. By manipulating the “backupFile” parameter, attackers could write files to arbitrary locations on the system using directory traversal techniques. However, researchers soon discovered a more severe impact through chaining multiple behaviors.

A crucial step in the exploit chain involves injecting a PostgreSQL connection string into the “database” parameter. This allows attackers to override default connection settings, forcing Splunk to connect to an attacker-controlled database. Consequently, malicious database content can be written directly to the Splunk filesystem.

Further investigation by watchTowr revealed that Splunk’s restore feature can utilize credentials stored in a local .pgpass file. Attackers can exploit this to abuse exposed database credentials during restore operations, authenticate to the internal PostgreSQL instance, and execute arbitrary SQL commands during the restoration process.

Researchers demonstrated that carefully crafted SQL payloads could write attacker-controlled files to disk using PostgreSQL large object export functions. This capability grants full arbitrary file write access under the Splunk user account. With this level of file write access, achieving remote code execution becomes a straightforward process. In their proof-of-concept, attackers overwrote a legitimate Splunk Python script that executes during normal operations, allowing them to execute system commands and confirm code execution on the target system.

This vulnerability underscores how internal services, when exposed through proxy mechanisms, can undermine fundamental security assumptions, especially when authentication is inconsistently enforced. Even services bound to localhost can become remotely accessible via application-layer routing.

What You Should Do

• Apply Updates Immediately: Splunk has released an advisory and urges all users to update affected versions of Splunk Enterprise without delay.
• Prioritize Cloud Deployments: Organizations using Splunk Enterprise on AWS should prioritize patching, as the vulnerable PostgreSQL Sidecar Service is enabled by default in these environments.
• Monitor API Endpoints: Implement robust monitoring for access to internal API endpoints and restrict any unnecessary exposure.
• Review File Integrity: Regularly review and verify the file integrity of critical Splunk components to detect any unauthorized modifications.
• Utilize Detection Tools: Employ detection tools developed by security researchers to help identify vulnerable systems by testing access-control behaviors.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.