Critical Splunk Enterprise Flaw Allows Attackers to Execute Code Without Authentication
Splunk has released security updates to address a critical security issue in Splunk Enterprise that could be used for unauthorized file operations and remote code execution.
Vulnerability, tracked as CVE-2026-20253rated 9.8 in the CVSS scoring system.
“In Splunk Enterprise versions below 10.2.4 and 10.0.7, an unauthorized user can create or truncate arbitrary files by using the PostgreSQL sidecar service endpoint,” Splunk said in an alert this week.
“The vulnerability exists because the PostgreSQL sidecar service endpoint lacks authentication controls, allowing any network-accessible user to request file operations without credentials.”
The issue has been addressed in the following versions –
- Splunk Enterprise 10.0.0 to 10.0.6 – Fixed in 10.0.7
- Splunk Enterprise 10.2.0 to 10.2.3 – Fixed in 10.2.4
- Splunk Enterprise 10.4 – Untouchable
Splunk, which is part of Cisco, said that Splunk Cloud is not affected by the vulnerability as Postgres sidecars are not used in production.
What is the Error
On Friday, watchTowr Labs released additional technical details for CVE-2026-20253, saying it can be exploited to achieve pre-authorized remote code execution on vulnerable systems via the “/v1/postgres/recovery/backup” and “/v1/postgres/recovery/recovers” endpoints.
The attack chain works like this –
- Connect to a database controlled by the attacker and dump its contents to a dummy file using the endpoint/backup endpoint
- Upload a dump of the attacker-controlled database to the local PostgreSQL environment using the /restore terminal by including the “passfile” argument specifying the path to the “.pgpass” file (“/opt/splunk/var/packages/data/postgres/.pgpass”) that contains the password for the “postgres_admin” user.
- SQL queries defined in the database dump will be executed by Splunk’s PostgreSQL instance
An attacker can use this vulnerability to define a new function that uses lo_export – a function used to extract a BLOB from a database and save it as a file in the file system – to write the content controlled by the attacker to the file, following which the function is used during the recovery process.
“Currently, we can authenticate, restore SQL controlled by attackers, and interact with local databases,” security researchers Piotr Bazydlo and Yordan Ganchev said. “Once we were able to restore the attacker’s controlled SQL to local PostgreSQL, we quickly compiled a database dump template that gave us controlled file writing.”
Armed with an arbitrary file that writes first to the Splunk file system, an attacker can advance to remote code execution by overwriting the Python script that Splunk uses regularly (eg, “/opt/splunk/etc/apps/splunk_secure_gateway/bin/ssgmodular_enable”).
The entire sequence of actions is below –
- Create a database and configure it in such a way that the user can authenticate without a password and give it sufficient permissions to invoke operations such as lo_export
- Use the endpoint/backup endpoint to drop remote database dumps to the Splunk file system
- Use the /restore endpoint to upload a malicious database dump, trigger the execution of a malicious operation during the restore process, and write an attacker-controlled Python script to the Splunk file system.
While there is no evidence that this flaw is being exploited in the wild, the discovery of exploit information may be enough to prompt threat actors to launch opportunistic efforts. It is important that users move quickly to apply fixes to stay protected.
