Critical Pre-Auth RCE Risk in Splunk Enterprise: CVE-2026-20253

Splunk has released emergency security updates to address the critical vulnerability CVE-2026-20253, rated CVSS 9.8, in Splunk Enterprise. The vulnerability allows an unauthenticated attacker to create and truncate arbitrary files via an unsecured PostgreSQL sidecar endpoint, which, according to researchers from watchTowr Labs, can be developed into full remote code execution (RCE) without prior authentication. Versions 10.0.0–10.0.6 and 10.2.0–10.2.3 are affected; fixes are available in versions 10.0.7 and 10.2.4. Splunk Cloud is not affected. Given the publication of technical exploitation details, applying the update should be treated as a top-priority task.

Nature of the vulnerability

According to the official Splunk advisory, the root cause of the issue is the complete absence of authentication on the PostgreSQL sidecar endpoint. Any user with network access to a vulnerable Splunk Enterprise instance can invoke file operations without providing credentials. The vendor states it as follows: an unauthenticated user can create or truncate arbitrary files via the PostgreSQL sidecar service endpoint.

Affected and fixed versions:

• Splunk Enterprise 10.0.0–10.0.6 — fixed in version 10.0.7
• Splunk Enterprise 10.2.0–10.2.3 — fixed in version 10.2.4
• Splunk Enterprise 10.4 — not affected
• Splunk Cloud — not affected (the PostgreSQL sidecar is not used in the cloud product)

Exploitation chain: from file writes to RCE

Researchers Piotr Bazydlo and Yordan Ganchev from watchTowr Labs have published a detailed technical analysis describing the path from a file write primitive to full arbitrary code execution. It is important to note: the vendor advisory confirms the possibility of unauthenticated file operations, whereas the complete RCE chain is described by the researchers and has not yet been independently confirmed.

According to the researchers, the attack uses two endpoints:

• /v1/postgres/recovery/backup — to connect to an attacker-controlled database and dump its contents into an arbitrary file on the Splunk file system
• /v1/postgres/recovery/restore — to load a malicious dump into the local PostgreSQL instance using the passfile parameter, which points to the file /opt/splunk/var/packages/data/postgres/.pgpass containing the password for the postgres_admin user

The key element of the attack is that SQL queries embedded in the database dump are executed by the PostgreSQL instance during the restore process. This allows the attacker to define a user function that uses lo_export, a standard PostgreSQL mechanism for exporting large objects (BLOBs) to files on disk. Through this function, the attacker gains a primitive for writing attacker-controlled content to the file system.

To escalate to code execution, according to watchTowr Labs, it is sufficient to overwrite a Python script that Splunk executes regularly — for example, /opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py. Once overwritten, the malicious code is executed in the context of the Splunk process.

Full attack sequence

1. The attacker creates an external PostgreSQL database with a configuration that allows passwordless authentication and grants sufficient privileges to call functions such as CREATE FUNCTION and lo_export
2. Via the /backup endpoint, a dump of this database is placed on the Splunk file system
3. Via the /restore endpoint, the malicious dump is loaded into the local PostgreSQL instance; during restoration, the malicious function is triggered, writing an attacker-controlled Python script to disk

Impact assessment

Splunk Enterprise is one of the most widely used SIEM platforms, employed for aggregating and analyzing security logs in organizations of any size. Compromise of a SIEM system poses a particular threat: the attacker gains not only control over the server itself, but also potential access to security logs for the entire infrastructure, which can be used to plan further attacks and cover their tracks.

The CVSS 9.8 score reflects the criticality: the attack requires no authentication, can be carried out remotely, and leads to complete compromise of confidentiality, integrity, and availability. Organizations whose Splunk Enterprise instances are accessible from untrusted network segments are at the greatest risk.

At the time of publication, no confirmed cases of exploitation in real-world attacks have been recorded, and the vulnerability has not been added to the CISA KEV catalog. However, the publication of a detailed technical description of the exploitation chain significantly increases the likelihood of opportunistic attacks in the coming days.

Recommendations

• Immediately update Splunk Enterprise to versions 10.0.7 or 10.2.4, depending on the branch you are using
• Restrict network access to the /v1/postgres/recovery/backup and /v1/postgres/recovery/restore endpoints using network segmentation and firewalls — as a temporary measure until the update is applied
• Verify the integrity of Python scripts in the /opt/splunk/etc/apps/ directory, in particular the ssg_enable_modular_input.py file, for any unauthorized changes
• Analyze access logs for the PostgreSQL sidecar for requests to the specified endpoints originating from unauthorized sources
• If you are using Splunk Enterprise version 10.4 or Splunk Cloud, no update is required; these products are not affected

The combination of maximum criticality (CVSS 9.8), the absence of any authentication requirement, and a publicly available description of the full exploitation chain makes CVE-2026-20253 one of the highest-priority vulnerabilities for immediate remediation. Organizations using affected versions of Splunk Enterprise should apply updates as part of an emergency patch cycle, without waiting for a scheduled maintenance window, and until the update is applied, should isolate the PostgreSQL sidecar from untrusted networks.