Splunk CVE-2026-20253: Unauthenticated Remote Code Execution Vulnerability Explained

On June 10, 2026, Splunk disclosed a critical security flaw in Splunk Enterprise that allows an unauthenticated attacker to achieve remote code execution [1]. Tracked as CVE-2026-20253, the vulnerability has a CVSS score of 9.8 (Critical). Since Splunk Enterprise sits at the heart of many security operations centers and ingests sensitive log data from across an organization, a pre-authentication remote code execution flaw in the product carries serious implications. The very platform that teams rely on to detect attacks can itself become the foothold.

In this blog, we explain how the Splunk CVE-2026-20253 vulnerability works and provide practical steps for validation and remediation.

Splunk CVE-2026-20253 Vulnerability Explained

Splunk Enterprise is a software platform for searching, monitoring, and analyzing machine-generated data at scale. It ingests logs, metrics, and event data from across an organization's IT environment, including servers, applications, network devices, and security tools, and indexes that data so it can be queried in near real time.

On June 10, 2026, Splunk disclosed a critical authentication flaw in the PostgreSQL sidecar service endpoint of Splunk Enterprise. The CVE-2026-20253 vulnerability is described as an unauthenticated arbitrary file creation and truncation flaw. The root cause is simple to state. The sidecar service exposes file operation endpoints that perform no application-level authentication, so any user who can reach the service over the network can invoke them without credentials.

The advisory lists no mitigations or workarounds, so patching is the primary defense. Organizations running affected versions should apply patches as soon as possible. Teams running Splunk Enterprise on AWS should treat this as especially urgent, given that the vulnerable sidecar is enabled by default. While there is no public evidence of exploitation in the wild at the time of disclosure, the availability of detailed exploit specifics is more than enough to drive opportunistic attempts, so rapid patching matters.

Splunk Cloud Platform is not affected, because Postgres sidecars are not used in that product. Splunk has stated that it is actively monitoring and patching Splunk Cloud instances regardless.

How the Splunk CVE-2026-20253 Exploit Works

This vulnerability starts as what looks like an arbitrary file creation issue, but researchers showed it can be chained into full unauthenticated remote code execution. The attack works because several small weaknesses can be combined into a complete compromise.

Step 1: Accessing an Internal Service

Splunk includes a PostgreSQL sidecar service that listens only on the local machine (port 5435). Normally, services bound to localhost are not reachable from the network. However, Splunk's main web interface can forward requests to this internal service. An attacker can send requests to the public Splunk web server and have them relayed to PostgreSQL recovery endpoints, such as /en-US/splunkd/__raw/v1/postgres/recovery/backup. As a result, a service that appears isolated becomes reachable from outside the system. The sidecar exposes several endpoints, including the following.

Step 2: Bypassing Authentication

The recovery endpoints expect an HTTP Basic authorization header, which would normally suggest that credentials are required. In practice, any credentials are accepted, including empty ones. Whatever username is provided is simply passed to PostgreSQL tools such as pg_dump, while the sidecar service performs no authentication of its own. A request carrying an empty Authorization: Basic Og== value (which decodes to a blank username and password) is enough to invoke the backup operation and receive a success response.

Step 3: Gaining Arbitrary File Creation

The backupFile parameter is used directly as the output path for pg_dump. Because it is not constrained to a safe directory, an attacker can supply a path traversal sequence and have the file created anywhere the Splunk user can write. A request with a backupFile value, such as ../../../../../../tmp/backuptest results, in an empty file at the chosen location.

At this point, the attacker can create an empty file at any path and, because the write overwrites existing content, can truncate or clear any file the service can reach. By itself, this is damaging but not yet a full system compromise.

Step 4: Turning Empty Files into Real Content

Initially, files created through the backup process are empty because the attacker cannot authenticate to the local database. Researchers discovered that PostgreSQL allows the database name parameter to contain a full connection string, and any connection parameters inside that string override conflicting command line options [2].

The sidecar hardcodes -h localhost, but an attacker can place a hostaddr parameter inside the database value and force pg_dump to connect to an attacker-controlled PostgreSQL server instead. By standing up a database that allows password free authentication from any host and granting it the right privileges, the attacker can have Splunk dump the contents of that remote attacker database onto the Splunk file system, this time with real content rather than an empty file.

Step 5: Accessing the Local Database

To achieve full compromise, the attacker still needs access to Splunk's local PostgreSQL instance. Researchers found that Splunk stores PostgreSQL credentials in a .pgpass file on disk at /opt/splunk/var/packages/data/postgres/.pgpass. PostgreSQL supports a parameter that tells it where to find such a credentials file. By pointing PostgreSQL to Splunk's own .pgpass file, the attacker can authenticate as the privileged database user without knowing the password.

Step 6: Turning Database Restore into Arbitrary File Write

The restore endpoint loads database backups and executes the SQL statements contained within them. Since the attacker controls the backup file, they also control the SQL that gets executed during restoration. Researchers created a malicious database backup containing SQL that writes attacker-controlled content to arbitrary files on the operating system. At this point, the vulnerability has evolved from file creation into a fully controlled arbitrary file write primitive.

Step 7: Achieving Remote Code Execution

Once an attacker can write arbitrary files, code execution becomes straightforward.

The researchers identified a Python script, located at /opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py, within Splunk that is executed regularly. By replacing that script with attacker-controlled code, they ensured their payload would eventually run under the Splunk service account.

The final result is unauthenticated remote code execution from a network accessible Splunk web interface. An attacker can go from a single HTTP request path to executing commands on the server without valid credentials.

How Picus Helps Simulate Splunk CVE-2026-20253 Attacks?

We also strongly suggest simulating the Splunk CVE-2026-20253 vulnerability to test the effectiveness of your security controls against sophisticated cyber attacks using the Picus Security Validation Platform. You can also test your defenses against other vulnerability exploitation attacks, such as regreSSHion, Citrix Bleed, and Follina, within minutes with a 14-day free trial of the Picus Platform.

Picus Threat Library includes the following threats for Splunk CVE-2026-20253 exploitation attacks:

Picus also provides actionable mitigation content. Picus Mitigation Library includes prevention signatures to address Splunk CVE-2026-20253 vulnerability exploitation attacks in preventive security controls. Currently, Picus Labs has validated the following signatures for Splunk CVE-2026-20253 vulnerability:

Start simulating emerging threats today and get actionable mitigation insights with a  14-day free trial  of the Picus Security Validation Platform.

References

[1] Splunk Vulnerability Disclosure. n.d. "Unauthenticated Arbitrary File Creation and Truncation in a PostgreSQL Sidecar Service Endpoint in Splunk Enterprise." Accessed June 15, 2026. https://advisory.splunk.com/advisories/SVD-2026-0603

[2] Bazydlo, Piotr. 2026. "Why Use App-Level Auth When Every Database Has Auth? (Splunk Enterprise CVE-2026-20253 Pre-Auth RCE)." watchTowr Labs, June 12. https://labs.watchtowr.com/why-use-app-level-auth-when-every-database-has-auth-splunk-enterprise-cve-2026-20253-pre-auth-rce/