Critical Splunk Enterprise Flaw Lets Attackers Run Code Without Authentication

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.”