Splunk has released a security update to address a critical security flaw in Splunk Enterprise that could be used for unauthenticated file operations and even remote code execution.
Vulnerability, tracked as CVE-2026-20253It is rated 9.8 on the CVSS scoring system.
“In Splunk Enterprise versions below 10.2.4 and 10.0.7, an unauthenticated user can create or truncate arbitrary files through the PostgreSQL sidecar service endpoint,” Splunk said in an alert this week.
“The vulnerability exists because the PostgreSQL sidecar service endpoint lacks authentication controls, which allows any network-accessible user to initiate file operations without credentials.”
This issue has been addressed in the following versions –
- Fixed in Splunk Enterprise 10.0.0 to 10.0.6 – 10.0.7
- Fixed in Splunk Enterprise 10.2.0 to 10.2.3 – 10.2.4
- Splunk Enterprise 10.4 – Not affected
Splunk, which is part of Cisco, said Splunk Cloud is not affected by the vulnerability because the Postgres sidecar is not used in the product.
What is the fault?
On Friday, Watchtower Labs released additional technical details of CVE-2026-20253, saying it can be used to gain pre-authenticated remote code execution on vulnerable systems via the “/v1/postgres/recovery/backup” and “/v1/postgres/recovery/restore” endpoints.
The attack chain works like this –
- Connect to an attacker-controlled database and dump its contents to an arbitrary file using the /backup endpoint
- Load a dump of the attacker-controlled database into a local PostgreSQL instance using the /restore endpoint by including the “passfile” argument that specifies the path to a “.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 the PostgreSQL instance of Splunk
An attacker could weaponize this vulnerability to define a new function that uses lo_export – a function used to extract a BLOB from the database and save it as a file on the file system – to write the attacker-controlled contents to a file, after which the function is executed during the restore process.
“At this point, we can authenticate, restore attacker-controlled SQL, and interact with the local database,” said security researchers Piotr Bazydlo and Yordan Ganchev. “Once we could restore the attacker-controlled SQL to the local PostgreSQL instance, we immediately created a database dump template that allowed us to write a controlled file.”
Armed with an arbitrary file write primitive on the Splunk file system, an attacker can proceed to remote code execution by overwriting the Python script that Splunk frequently executes to include a malicious payload (for example, “/opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py”).
The complete sequence of actions is below –
- Create a database and configure it so that users can authenticate without a password and give it enough permissions to initiate tasks like lo_export.
- Use the /backup endpoint to drop a dump of a remote database onto the Splunk file system
- Use the /restore endpoint to load a malicious database dump, trigger the execution of a malicious function during the restore process, and write an attacker-controlled Python script into the Splunk file system.
Although there is no evidence that this flaw is being exploited in the wild, the availability of the exploit specifications may be enough to motivate threat actors to launch opportunistic attempts. It is essential that users move quickly to implement fixes to stay protected.
