Splunk has released security updates to address a critical security flaw in Splunk Enterprise that could be exploited to conduct unauthenticated file operations and even remote code execution.
The vulnerability, tracked as CVE-2026-20253, is rated 9.8 on the CVSS scoring system.
“In Splunk Enterprise versions below 10.2.4 and 10.0.7, an unauthenticated user could create or truncate arbitrary files through a 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-reachable user to invoke 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 – Not affected
Splunk, which is part of Cisco, said Splunk Cloud is not impacted by the vulnerability as Postgres sidecars are not used in the product.
What the Flaw is All About
On Friday, watchTowr Labs released additional technical details of CVE-2026-20253, stating it could be exploited to achieve pre-authenticated remote code execution on susceptible systems through the “/v1/postgres/recovery/backup” and “/v1/postgres/recovery/restore” endpoints.
The attack chain works as follows –
- Connect to an attacker-controlled database and dump its contents into an arbitrary file using the /backup endpoint
- Load the dump of the attacker-controlled database into the local PostgreSQL instance using the /restore endpoint by including a “passfile” argument that specifies the path to a “.pgpass” file (“/opt/splunk/var/packages/data/postgres/.pgpass”) containing the password for the “postgres_admin” user
- SQL queries defined in the database dump will get executed by Splunk’s PostgreSQL instance
An attacker could weaponize this weakness 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 attacker-controlled content to a file, following which the function gets executed during the restoration process.
“At this point, we can authenticate, restore attacker-controlled SQL, and interact with the local database,” security researchers Piotr Bazydlo and Yordan Ganchev said. “Once we could restore attacker-controlled SQL into the local PostgreSQL instance, we quickly put together a database dump template that gave us a controlled file write.”
Armed with an arbitrary file write primitive on the Splunk file system, an attacker could escalate further to remote code execution by overwriting a Python script that Splunk frequently executes (e.g., “/opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py”) to include the malicious payload.
The entire sequence of actions is below –
- Create a database and configure it such that a user can authenticate without a password and grant it sufficient permissions to invoke functions like lo_export
- Use the /backup endpoint to drop a dump of the remote database onto the Splunk file system
- Use the /restore endpoint to load the malicious database dump, trigger execution of the malicious function during the restore process, and write an attacker-controlled Python script to the Splunk file system
Although there is no evidence of the flaw being exploited in the wild, the availability of the exploit specifics can be enough to drive threat actors to trigger opportunistic attempts. It’s essential that users move quickly to apply the fixes to stay protected.
