Splunk Patches Critical Unauthenticated RCE Flaw in Enterprise Software

Splunk released security updates this week to fix a critical flaw in Splunk Enterprise that lets unauthenticated attackers perform arbitrary file operations and achieve remote code execution. The vulnerability, tracked as CVE 2026 20253, affects all versions below 10.2.4 and 10.0.7.

The bug carries a CVSS score of 9.8, placing it in the most severe category. On Friday, watchTowr Labs published technical details showing how an attacker can chain two unauthenticated endpoints to gain full code execution without any credentials.

PostgreSQL Sidecar Lacks Authentication Controls

The issue lies in Splunk Enterprise's PostgreSQL sidecar service endpoint. An unauthenticated user can call the "/v1/postgres/recovery/backup" and "/v1/postgres/recovery/restore" endpoints to interact with the local database. The attack chain proceeds as follows:

• Connect to an attacker controlled PostgreSQL database and dump its contents into an arbitrary file using the backup endpoint.
• Use the restore endpoint to load the malicious dump, providing a passfile argument that points to Splunk's .pgpass file to obtain the postgres_admin password.
• The loaded SQL dump executes during restoration, allowing the attacker to define a function that uses the lo_export feature to write attacker controlled content to a file.
• Overwrite a frequently executed Python script in Splunk's apps directory (e.g., splunk_secure_gateway/bin/ssg_enable_modular_input.py) to inject malicious code and achieve remote code execution.

No Active Exploitation Reported, But Risk Is High

Splunk, which is owned by Cisco, confirmed that Splunk Cloud is not affected because it does not use PostgreSQL sidecars. The company urged all on premises customers to update to Splunk Enterprise 10.2.4 or 10.0.7 immediately. Although there is no evidence of the flaw being exploited in the wild, the publication of exploit details will likely trigger opportunistic attacks.

Organizations running affected versions should prioritize patching, especially if the Splunk management interface is exposed to internal networks. The vulnerability underscores the risk of unauthenticated API endpoints in data intensive applications.