Splunk has issued security updates to address a critical security vulnerability in Splunk Enterprise that could allow unauthorized file operations and even remote code execution.
The flaw, identified as CVE-2026-20253, carries a CVSS score of 9.8.
"In Splunk Enterprise versions prior to 10.2.4 and 10.0.7, an unauthenticated user could create or truncate arbitrary files via a PostgreSQL sidecar service endpoint," Splunk stated in an advisory this week.
"The issue arises because the PostgreSQL sidecar service endpoint lacks authentication controls, enabling any network-accessible user to perform file operations without needing credentials."
The problem has been resolved in the following releases:
Splunk Enterprise 10.0.0 through 10.0.6 - Patched in 10.0.7
Splunk Enterprise 10.2.0 through 10.2.3 - Patched in 10.2.4
Splunk Enterprise 10.4 - Unaffected
Splunk, a Cisco-owned company, noted that Splunk Cloud is not affected by this vulnerability because Postgres sidecars are not employed in that product.
Understanding the Vulnerability
On Friday, watchTowr Labs released further technical details about CVE-2026-20253, indicating that it could be leveraged to achieve pre-authentication remote code execution on vulnerable systems through the "/v1/postgres/recovery/backup" and "/v1/postgres/recovery/restore" endpoints.
The attack chain proceeds as follows:
Connect to a database under attacker control and export its contents to an arbitrary file using the /backup endpoint
Load the exported data from the attacker-controlled database into the local PostgreSQL instance via the /restore endpoint, supplying a "passfile" argument pointing to a ".pgpass" file ("/opt/splunk/var/packages/data/postgres/.pgpass") that holds the password for the "postgres_admin" user
SQL queries embedded in the database dump will be executed by Splunk's PostgreSQL instance
An attacker could exploit this vulnerability to define a new function that employs lo_export—a function designed 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, after which the function runs during the restoration process.
"At this stage, we can authenticate, restore attacker-controlled SQL, and interact with the local database," security researchers Piotr Bazydlo and Yordan Ganchev explained. "Once we could restore attacker-controlled SQL into the local PostgreSQL instance, we quickly assembled a database dump template that provided us with a controlled file write."
With the ability to perform arbitrary file writes on the Splunk file system, an attacker could escalate to remote code execution by overwriting a Python script that Splunk runs frequently (e.g., "/opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py") to insert malicious payload.
The full sequence of steps is as follows:
Set up a database and configure it so a user can authenticate without a password, granting sufficient permissions to invoke functions like lo_export
Use the /backup endpoint to place a dump of the remote database onto the Splunk file system
Use the /restore endpoint to load the malicious database dump, triggering execution of the malicious function during restoration, and write an attacker-controlled Python script to the Splunk file system
While there is no evidence that the flaw has been exploited in the wild, the release of exploit details could be enough to prompt threat actors to launch opportunistic attacks. It is crucial that users act quickly to apply the patches to remain protected.