On June 10th, Splunk released an advisory regarding CVE-2026-20253, which has caught the attention of security researchers due to its notable characteristics. The advisory details a vulnerability that requires no authentication, boasts a high CVSS score of 9.8, and is associated with a product that is fundamentally designed for security. The name of the vulnerability itself is almost as long as a piece of spaghetti, adding a touch of irony to the situation.
Despite the lack of explicit mention of Remote Code Execution (RCE), the high CVSS score raises questions about the potential severity of the issue. It remains unclear whether this vulnerability is present in default installations or if specific configurations are necessary for exploitation.
What Is A Splunk?
Splunk Enterprise serves as a robust platform for searching, monitoring, and analyzing machine-generated data across IT environments. It aggregates logs, metrics, and event data from various sources, indexing them for near real-time querying via its Search Processing Language (SPL). This capability allows teams to create dashboards, set alerts, and investigate operational or security issues from a unified interface, making it a cornerstone of the broader Splunk ecosystem.
So, Is It Vulnerable By Default?
The advisory indicates that the vulnerability resides within the “PostgreSQL Sidecar Service Endpoint.” Splunk’s installation can vary significantly, leading to different configurations:
- For Splunk Enterprise On-Premise installed manually on Windows, the PostgreSQL Sidecar Service is not installed by default.
- In some cases, it may be installed but not enabled by default.
- Conversely, when deployed on AWS, the PostgreSQL Sidecar Service is both installed and enabled by default.
In summary, Splunk Enterprise on AWS is vulnerable right out of the box. The vulnerability affects versions 10 and above, aligning with the introduction of the Sidecar concept in Splunk version 10.
Finding The Vulnerable Service
The advisory provides valuable hints, particularly that the vulnerability exists within the PostgreSQL Sidecar Service. A quick search reveals that all Sidecar Services are typically deployed in the /opt/splunk/var/run/supervisor/pkg-run/ directory. The service named splunk-postgres appears to be a promising candidate for further investigation.
Upon confirming that the service is indeed running and listening on several ports, we noted that these ports were bound only to the loopback interface. This led us to suspect that there might be more to explore beyond the apparent limitations of localhost access.
CVE-2026-20253 – The One With The File Write
As we delved deeper, we identified a potentially vulnerable API. The PostgreSQL Sidecar Service API listens on 127.0.0.1:5435, and we hypothesized that it could be accessed through the main web application, which listens on all interfaces and port 8000. A test request confirmed our suspicions, revealing that the API lacked authentication controls, allowing any network-reachable user to invoke file operations without credentials.
Our exploration revealed that the PostgreSQL Sidecar Service could create and truncate arbitrary files. For instance, we successfully created an empty file named backuptest in the service directory, demonstrating the vulnerability’s potential impact.
Backup Endpoint – Going Further
With the ability to create empty files established, we sought to understand the extent of this vulnerability. The /v1/postgres/recovery/backup endpoint allowed us to specify a backupFile parameter, leading us to consider the implications of file creation at arbitrary locations within the filesystem.
By injecting a path traversal sequence into the backupFile parameter, we confirmed that we could create files outside the intended directory, further highlighting the risk associated with this vulnerability.
Restore(ing) The Faith
Next, we turned our attention to the /restore endpoint, which follows a similar structure to the /backup endpoint. This endpoint is designed to rebuild a database from a previously generated backup, allowing us to execute SQL commands contained within the backup file.
Our plan was straightforward: force Splunk to dump an attacker-controlled database into an arbitrary file using the /backup endpoint, and then load that dump into the local PostgreSQL instance via the /restore endpoint. This sequence would enable us to execute SQL commands defined in our database dump, potentially leading to further exploitation.
Through careful manipulation of the database connection parameters, we successfully connected to the local PostgreSQL instance and restored our attacker-controlled SQL commands. This opened the door to executing arbitrary code on the Splunk filesystem, effectively achieving RCE.
Detection Artefact Generator
In light of these findings, we have developed a Detection Artefact Generator to help organizations assess their susceptibility to this vulnerability. The tool determines whether a system is vulnerable based on the response to authentication attempts with any credentials in the Authorization header.
For those interested, the Detection Artefact Generator can be found here, along with detailed instructions for execution.
