Splunk Enterprise CVE-2026-20253 (CVSS 9.8): Unauthenticated RCE in the SIEM Monitoring Your Entire Infrastructure

Splunk Enterprise, the most widely deployed SIEM and security observability platform in corporate environments, has a critical unauthenticated remote code execution vulnerability. CVE-2026-20253 (CVSS 9.8) was published on 10 June 2026 in Splunk’s official advisory SVD-2026-0603. The root cause: the endpoints of Splunk Enterprise’s PostgreSQL Sidecar service have no authentication controls, allowing any network-reachable user to invoke file operations without credentials and, in an exploitation chain documented by watchTowr Labs and Orca Security, escalate to full remote code execution on the server. Affected versions are Splunk Enterprise 10.0.0–10.0.6 (fixed in 10.0.7) and 10.2.0–10.2.3 (fixed in 10.2.4). Splunk Cloud is not affected. The full technical PoC is being amplified today — the window to patch before a public exploit becomes widely available is closing.

‍

What do we know about CVE-2026-20253 and the pre-authenticated RCE chain?

Facts documented by Splunk (advisory SVD-2026-0603), watchTowr Labs, Orca Security, GBHackers, The Hacker News, SecurityWeek and The Cyber Express:

• Vulnerability: complete absence of authentication controls (CWE-306: Missing Authentication for Critical Function) on Splunk Enterprise’s PostgreSQL Sidecar service. The HTTP endpoints /v1/postgres/recovery/backup and /v1/postgres/recovery/restore are accessible to any network-reachable user without credentials.
• CVSS 9.8 (Critical): network attack vector, no prior privileges, no user interaction, confidentiality and integrity completely compromised.
• Affected versions: Splunk Enterprise 10.0.0–10.0.6 (patched in 10.0.7) and 10.2.0–10.2.3 (patched in 10.2.4). The PostgreSQL Sidecar component was introduced in Splunk Enterprise v10, so versions prior to 10.x are not affected.
• Splunk Cloud is NOT affected: Splunk’s managed platform does not use PostgreSQL sidecars.
• Splunk Enterprise on AWS is the highest-risk case: the PostgreSQL Sidecar Service is enabled and active by default in Splunk Enterprise deployments on AWS, making those instances vulnerable out of the box.
• Access via Splunk’s proxy: although the PostgreSQL Sidecar service listens on localhost, it is accessible externally through Splunk’s main web interface proxy mechanism. Any attacker reaching Splunk’s web port can reach these vulnerable endpoints.
• Additional CVEs published in the same advisory: CVE-2026-20251 (CVSS 8.8): RCE via unsafe deserialization of App Key Value Store (KV Store) data through the Python jsonpickle library in the Splunk Secure Gateway app. Requires a low-privilege user. CVE-2026-20258: XSS and SSRF in Splunk Secure Gateway.

‍

Why compromising the SIEM means compromising your entire organisation’s security

CVE-2026-20253 is not a vulnerability in a web server or a peripheral database. Splunk Enterprise is the SIEM — the system where all organisational security telemetry converges. Compromising Splunk with code execution access has implications far beyond the server itself:

1. An attacker with RCE on Splunk has access to all security logs. Splunk ingests logs from firewalls, endpoints, authentication servers, critical applications and cloud systems. With code execution on the server, an attacker can read, exfiltrate or manipulate all that telemetry.
2. The attacker can blind the SOC team. Splunk is the console from which the security team detects and responds to incidents. An attacker with RCE can delete or alter logs, disable alerts, modify dashboards, and essentially operate invisibly inside the network while the SOC sees whatever the attacker wants it to see.
3. Splunk integration credentials are access keys to the entire infrastructure. Splunk connects via API keys and tokens to every system it monitors: cloud providers (AWS, Azure, GCP), Active Directory, ITSM systems, ticketing tools, CI/CD pipelines. The Splunk server stores or references all those credentials. With RCE, an attacker can exfiltrate all of them.
4. Access to the .pgpass file. The exploitation chain documented by watchTowr Labs includes access to PostgreSQL’s .pgpass file, which stores database credentials in plain text.

‍

How the CVE-2026-20253 exploitation chain works

1. Accessing the endpoints without authentication. The attacker sends HTTP requests to the vulnerable PostgreSQL Sidecar endpoints through Splunk’s web interface proxy. No credentials required.
2. Arbitrary file writes via lo_export. The backup and restore endpoints interact with PostgreSQL, allowing the attacker to abuse PostgreSQL’s lo_export function, which extracts a BLOB from the database and saves it as a file on the server filesystem. The attacker can create a malicious BLOB and export it to any filesystem path with Splunk process permissions.
3. Escalation to RCE by overwriting Python scripts. Splunk executes Python scripts for multiple internal functions. By overwriting a Python script that Splunk executes with attacker-controlled content, the malicious code runs in the context of the Splunk process on the next script execution.
4. Credential access via .pgpass. As an additional step, the attacker can read the PostgreSQL .pgpass file, obtaining database credentials in plain text.

‍

Key lessons and mitigation checklist for Splunk Enterprise administrators

Step 1 — Verify exposure (immediate):

• Confirm the installed Splunk Enterprise version. If 10.0.0–10.0.6 or 10.2.0–10.2.3, the instance is vulnerable.
• Check whether the PostgreSQL Sidecar Service is active: $SPLUNK_HOME/bin/splunk status splunk-postgresql-sidecar.
• Verify whether vulnerable endpoints are reachable from untrusted networks through Splunk’s proxy.

Step 2 — Urgent update (priority action):

• Update Splunk Enterprise to 10.0.7 or higher (10.0.x branch) or 10.2.4 or higher (10.2.x branch). Consult advisory SVD-2026-0603 at advisory.splunk.com.
• Also apply patches for CVE-2026-20251 (Secure Gateway RCE) and CVE-2026-20258 (XSS/SSRF) included in the same fixed versions.

Step 3 — Temporary mitigations if patching cannot be done today:

• Disable the PostgreSQL Sidecar Service if not operationally required: $SPLUNK_HOME/bin/splunk disable splunk-postgresql-sidecar.
• Block access to vulnerable endpoints via WAF or network rules preventing access to /v1/postgres/recovery/* from untrusted networks.
• Isolate Splunk from direct external access if not architecturally required: Splunk should not be internet-facing in most corporate environments.

Step 4 — Forensic investigation (if the system may have been exposed since 10 June):

• Review Splunk’s web server access logs for requests to /v1/postgres/recovery/backup and /v1/postgres/recovery/restore since 10 June.
• Audit the server filesystem for recently created or modified files in paths where the Splunk process has write permissions.
• Verify the integrity of Python scripts in the Splunk directory for unauthorised modifications.
• Review the PostgreSQL .pgpass file and rotate credentials if compromise is suspected.

‍

Cybersecurity as a strategic priority

CVE-2026-20253 in Splunk Enterprise is a reminder that security tools are also attack surface. A SIEM with a critical RCE vulnerability does not protect the organisation — it is the vector through which the organisation can be completely and invisibly compromised. The 2026 DBIR, analysed three weeks ago, confirmed that unpatched vulnerabilities are the #1 breach vector. CVE-2026-20253 is the most direct manifestation of that pattern: a component introduced in Splunk v10 with no authentication controls, published on 10 June with full technical detail, with a PoC being amplified today. Spanish organisations using Splunk Enterprise on-premises have a very short window before the technical exploitation barrier drops to zero.

‍

Apolo Cybersecurity: Splunk Enterprise assessment and protection for CVE-2026-20253

At Apolo Cybersecurity we help organisations with Splunk Enterprise verify exposure to CVE-2026-20253: installed version and PostgreSQL Sidecar service status verification, urgent application of patch SVD-2026-0603, temporary mitigation implementation while the update is planned, forensic access log review from 10 June, and network segmentation assessment around Splunk infrastructure.

If your organisation uses Splunk Enterprise 10.x on-premises and has not applied the update to 10.0.7 or 10.2.4, this Monday morning is the time to do it. The system meant to detect attacks cannot be the attack entry point.

‍