--- title: "Critical Splunk Enterprise Flaw (CVE-2026-20253) Under Active Exploitation: Pre-Auth RCE via PostgreSQL Sidecar" url: https://radicalnotion.ai/blog/critical-splunk-enterprise-flaw-cve-2026-20253-under-active-exploitation-pre-auth-rce-via-postgresql-20260619125623 type: article description: "A critical CVSS 9.8 vulnerability in Splunk Enterprise's PostgreSQL sidecar allows unauthenticated attackers to achieve remote code execution. CISA has added it to the KEV catalog amid confirmed in-the-wild exploitation." updated: 2026-06-19 source: RadicalNotion.AI license: CC BY-NC 4.0 (https://creativecommons.org/licenses/by-nc/4.0/) --- # Critical Splunk Enterprise Flaw (CVE-2026-20253) Under Active Exploitation: Pre-Auth RCE via PostgreSQL Sidecar By Radical Notion Team, 2026-06-19 *A critical CVSS 9.8 vulnerability in Splunk Enterprise's PostgreSQL sidecar allows unauthenticated attackers to achieve remote code execution. CISA has added it to the KEV catalog amid confirmed in-the-wild exploitation.* A critical vulnerability in Splunk Enterprise — the workhorse logging and SIEM platform that sits at the heart of countless enterprise security operations centers — is being actively exploited in the wild, allowing unauthenticated attackers to seize complete control of affected servers. Tracked as **CVE-2026-20253**, the flaw carries a CVSS score of **9.8 (Critical)** and was added to the U.S. Cybersecurity and Infrastructure Security Agency's (CISA) Known Exploited Vulnerabilities (KEV) catalog on June 18, 2026, triggering federal patching mandates and amplifying the urgency for private-sector defenders. --- ## What Happened On June 10, 2026, Splunk's Product Security Incident Response Team (PSIRT) published advisory **SVD-2026-0603**, disclosing that an unauthenticated attacker could create or truncate arbitrary files on Splunk Enterprise hosts via an undocumented PostgreSQL "sidecar" service endpoint. The vendor's initial framing was relatively conservative — describing the issue as arbitrary file creation and truncation stemming from missing authentication (CWE-306) — but the severity score telegraphed that something far more dangerous was lurking beneath the surface. That suspicion was confirmed days later when researchers at **watchTowr Labs** published a detailed technical analysis and proof-of-concept demonstrating that the vulnerability could be reliably chained into **unauthenticated pre-authentication Remote Code Execution (RCE)**. The watchTowr write-up — titled *"Why Use App-Level Auth When Every Database Has Auth?"* — walks through how PostgreSQL's own connection string parsing quirks, combined with hardcoded credential files shipped inside Splunk, transform a seemingly contained file-write primitive into full system compromise as the `splunk` user. The vulnerability was discovered and reported by researcher **Alex Hordijk (hordalex)**, according to Splunk's credits. By June 18, 2026, CISA had added CVE-2026-20253 to the KEV catalog, citing active exploitation with the technical impact assessed as **"total"** and exploitation marked as **"automatable: yes"** — a combination that effectively guarantees mass scanning and opportunistic compromise. For an organization, a compromised Splunk server is a worst-case scenario: it is the system that holds the logs you would normally use to detect an intrusion, contains credentials and API keys for the rest of the environment, and often has privileged network reach into otherwise-segmented zones. --- ## Understanding the Vulnerability At its core, CVE-2026-20253 is a missing-authentication bug (CWE-306) in a PostgreSQL "sidecar" service that Splunk Enterprise 10.x bundles to support features like **Edge Processor**, **OpAmp**, and **SPL2 data pipelines**. The sidecar runs locally on `127.0.0.1:5435`, but — and this is the crucial design flaw — the main Splunk web application (`splunkd`, listening on port 8000) **proxies HTTP requests to the sidecar without enforcing authentication** on a specific set of recovery API endpoints. The two endpoints that matter are: - `POST /en-US/splunkd/__raw/v1/postgres/recovery/backup` - `POST /en-US/splunkd/__raw/v1/postgres/recovery/restore` These endpoints accept two JSON parameters — `database` and `backupFile` — and pass them more or less directly into the command-line arguments of `pg_dump` and `pg_restore`. While the developers hardcoded a `-h localhost` flag intending to constrain the database host to the local machine, PostgreSQL's `libpq` client library has a delightful (for attackers) feature: **the** `database` **argument can itself be a full connection string**, and parameters parsed from that string override earlier command-line arguments. That means an attacker can stuff a `hostaddr=` directive into the `database` parameter and force `pg_dump` to connect to a remote, attacker-controlled PostgreSQL server. They can also inject `passfile=/opt/splunk/var/packages/data/postgres/.pgpass` — pointing at a hardcoded Splunk credentials file shipped with the install — to authenticate locally without ever knowing a real password. From there, the attacker abuses PostgreSQL's `lo_export` SQL function, which writes the contents of a "large object" to an arbitrary file on the database server's filesystem. Combine that with the ability to control which SQL gets restored, and you have an arbitrary file write executing as the `splunk` system user. ### The Attack Chain, Step by Step Based on the watchTowr Labs technical analysis, the full exploitation chain unfolds as follows: 1. **Reconnaissance**: The attacker identifies a Splunk Enterprise 10.x instance exposing port 8000. A quick probe of `/en-US/splunkd/__raw/v1/postgres/recovery/backup` with an empty Basic Auth header returns an HTTP **400** on vulnerable systems (versus HTTP **401** on patched ones), confirming the target. 2. **Staging**: The attacker stands up a remote PostgreSQL server configured with passwordless authentication in `pg_hba.conf`. On this server, they create a database containing a malicious SQL function that uses `lo_export` to write attacker-supplied bytes to a chosen file path. 3. **Backup Injection (Pull the Payload)**: The attacker sends a POST request to `/en-US/splunkd/__raw/v1/postgres/recovery/backup` with empty Basic Auth credentials. The `database` JSON field contains `hostaddr=`, forcing `pg_dump` to connect to the attacker's PostgreSQL instance. The `backupFile` parameter specifies a local path on the Splunk server (e.g., somewhere under `/tmp` or `/opt/splunk/var/run/supervisor/pkg-run/`) where the malicious dump is written. 4. **Restore Injection (Execute the Payload)**: The attacker sends a second POST to `/en-US/splunkd/__raw/v1/postgres/recovery/restore`, this time setting `database` to `dbname=template1 passfile=/opt/splunk/var/packages/data/postgres/.pgpass`. This bypasses local PostgreSQL authentication using Splunk's own bundled credentials. The `backupFile` parameter points to the dump staged in Step 3. 5. **File Write via** `lo_export`: As PostgreSQL replays the dump, it executes the embedded `lo_export` call, writing the attacker's payload — typically a Python script — to a sensitive location on disk. A favored target is `/opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py`, a modular input script that Splunk executes regularly. 6. **Code Execution**: When Splunk next invokes the overwritten Python script, the attacker's code runs as the `splunk` user, completing the path from unauthenticated HTTP request to full RCE. Notably, the Splunk Cloud Platform is **not affected** because it does not use the PostgreSQL sidecar architecture. Splunk Enterprise **9.4 and earlier are also unaffected** — the sidecar was introduced in the 10.x line. And crucially, **Splunk Enterprise on AWS ships with the sidecar enabled by default**, making AWS-hosted deployments especially exposed out of the box. --- ## Who Is Affected | Vendor | Product | Affected Versions | Fixed Versions | | --- | --- | --- | --- | | Splunk | Splunk Enterprise | 10.2.0 – 10.2.3 | 10.2.4 | | Splunk | Splunk Enterprise | 10.0.0 – 10.0.6 | 10.0.7 | | Splunk | Splunk Enterprise | 10.x (all branches) | 10.4.0 | | Splunk | Splunk Enterprise on AWS | 10.x (sidecar enabled by default) | 10.0.7 / 10.2.4 / 10.4.0 | | Splunk | Splunk Cloud Platform | **Not Affected** | N/A | | Splunk | Splunk Enterprise 9.4 and earlier | **Not Affected** | N/A | Splunk is deployed in tens of thousands of enterprises worldwide, ranging from Fortune 500 companies and government agencies to managed security service providers. As a centralized data platform, it typically aggregates logs from across an organization's entire IT estate — endpoints, servers, network devices, cloud workloads, identity providers — making it a uniquely valuable target. A compromised Splunk instance is, effectively, a master key to understanding (and potentially erasing evidence of) activity across the rest of the environment. AWS deployments warrant special attention: because the PostgreSQL sidecar is enabled by default in the Splunk Enterprise on AWS distribution, **any unpatched 10.x AWS deployment is vulnerable without any additional configuration**. --- ## Real-World Risk The risk profile here is about as bad as it gets for an enterprise security tool: - **Active in-the-wild exploitation**: Splunk PSIRT updated its advisory on **June 18, 2026** to confirm limited active exploitation, and CISA added the CVE to the KEV catalog the same day. - **Public, weaponizable proof-of-concept**: watchTowr Labs has published both detection logic and exploitation primitives on GitHub (`watchtowrlabs/watchTowr-vs-Splunk-CVE-2026-20253`), dramatically lowering the bar for opportunistic attackers. - **Automatable**: CISA's SSVC assessment lists exploitation as `automatable: yes` with `Technical Impact: total` — a combination that historically correlates with mass scanning within days. - **Pre-authentication**: No credentials, no user interaction, no special privileges. If port 8000 is reachable, the box is reachable. If attackers achieve RCE as the `splunk` user, the worst-case scenarios include: - **Mass log exfiltration**: Splunk indexes are often a treasure trove of credentials, session tokens, internal hostnames, and sensitive business data inadvertently logged by applications. - **Tampering with security monitoring**: Attackers could alter or delete SIEM alerts, modify detection rules, and erase forensic evidence of their own activity — effectively blinding the SOC. - **Credential harvesting**: Splunk configurations frequently contain API keys, database connection strings, and integration credentials for ticketing systems, threat intel feeds, and cloud APIs. - **Lateral movement**: Splunk forwarders are deployed across the environment and often run with elevated privileges. A compromised indexer or search head can become a launchpad into otherwise-segmented network zones. The identities of threat actors currently exploiting CVE-2026-20253 have not been publicly disclosed, but the combination of automated exploitability and the high value of compromised SIEM infrastructure makes both opportunistic ransomware crews and nation-state actors likely participants. --- ## What You Should Do ### 1. Patch Immediately Upgrade affected Splunk Enterprise deployments to one of the following fixed versions, released on **June 10, 2026**: - **10.4.0** (the latest branch) - **10.2.4** (for the 10.2.x branch) - **10.0.7** (for the 10.0.x branch) Patches are available via the Splunk advisory at advisory.splunk.com/advisories/SVD-2026-0603 (https://advisory.splunk.com/advisories/SVD-2026-0603). For federal civilian agencies, the KEV listing triggers a binding remediation deadline under BOD 22-01. ### 2. Apply the Workaround if Patching Will Be Delayed If you cannot upgrade immediately, Splunk provides a full workaround: **disable the PostgreSQL sidecar**. Add the following stanza to `$SPLUNK_HOME/etc/system/local/server.conf`: ```plaintext [postgres] disabled = true ``` Then restart Splunk Enterprise. **Important caveat from Splunk**: Do **not** apply this workaround if you use any of the following features, as they depend on the sidecar: - **Edge Processor** - **OpAmp** - **SPL2 data pipelines** Disabling PostgreSQL will break these features and can cascade to dependent sidecar processes. Core search, indexing, and dashboard functionality are **not** affected by the workaround. ### 3. Restrict Network Exposure As a partial mitigation — and a defense-in-depth measure even after patching — ensure that Splunk Web (port 8000) is not directly exposed to the internet. Place it behind a VPN, identity-aware proxy, or strict ACLs allowing only management VLANs and trusted IP ranges. There is no legitimate reason for a Splunk management UI to be reachable from the public internet. ### 4. Hunt for Compromise Given confirmed in-the-wild exploitation, assume any internet-exposed vulnerable instance may already be compromised. Hunt for: **HTTP/Web Log Indicators**: - POST requests to `/en-US/splunkd/__raw/v1/postgres/recovery/backup` or `/en-US/splunkd/__raw/v1/postgres/recovery/restore` - Requests to those endpoints lacking proper `Authorization` headers but receiving HTTP 200 responses - Request bodies containing the strings `hostaddr=`, `passfile=`, or `../` **Process Telemetry**: - `pg_dump` or `pg_restore` invocations with unusual `-d` (database) argument values, especially those containing `hostaddr=` or `passfile=` - Unexpected outbound connections from the Splunk host to external PostgreSQL servers **File System Indicators**: - Unexpected files in `/opt/splunk/var/run/supervisor/pkg-run/` or `/tmp` - Modifications to Splunk-bundled Python scripts, especially `/opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py` - Anomalous use of `.pgpass` files in database connectivity logs **PostgreSQL Logs**: - Creation of database functions using the `lo_export` SQL function - Unexpected connections referencing the bundled `.pgpass` file A basic detection logic, drawn from the watchTowr PoC, distinguishes vulnerable from patched instances by response code: an HTTP **400** to an empty-auth POST against the recovery endpoints suggests vulnerability, while an HTTP **401** suggests the patch (or workaround) is in place. This same logic can be used by defenders to inventory exposure across their estate — and by attackers to find targets, which is precisely why patching cannot wait. ### 5. Rotate Credentials Stored in Splunk If you have any reason to suspect a compromise — or if your Splunk instance was internet-exposed during the exposure window — rotate any credentials, API keys, or service account passwords stored in Splunk configurations or apps. Assume any data that lived in indexes has been viewed. --- ## The Bigger Picture CVE-2026-20253 is a textbook example of a recurring architectural anti-pattern: **trusting the network boundary instead of authenticating at the application boundary**. The PostgreSQL sidecar was designed to listen only on `127.0.0.1`, on the implicit assumption that local-only binding constituted sufficient access control. That assumption held until the main `splunkd` web application began transparently proxying unauthenticated HTTP requests to it — at which point "localhost only" became "anyone with a browser." The watchTowr Labs analysis title says it bluntly: *Why use app-level auth when every database has auth?* The answer, of course, is that hardcoded `.pgpass` files shipped inside the application bundle ensured that the "database auth" was no auth at all from the perspective of anyone who could reach the proxy. There are two broader lessons here for defenders and developers alike. First, **sidecar architectures multiply the attack surface in subtle ways**: services that look isolated based on their listening interface can be silently re-exposed by any other component that proxies to them. Second, **vendor severity assessments and researcher findings can diverge significantly**. Splunk's original advisory framed this as arbitrary file creation and truncation — bad, but bounded. WatchTowr's chain to full RCE demonstrates how thin the line between "arbitrary file write" and "complete system compromise" really is, especially when the writable file system contains scripts the application itself executes. Defenders should generally assume that any unauthenticated file write primitive in a complex application can be escalated, and prioritize accordingly. Finally, expect more scrutiny of the broader sidecar ecosystem in Splunk and similar platforms. Where one architectural pattern hosts one unauthenticated endpoint, others are often hiding in adjacent code paths. The fact that researchers reached pre-auth RCE in days — and that exploitation followed soon after — suggests this will not be the last critical CVE we see in this class of components. Patch now, segment your management interfaces, and treat your SIEM with the same security rigor as the assets it monitors. ## Sources - [NVD - CVE-2026-20253](https://nvd.nist.gov/vuln/detail/CVE-2026-20253) - [Splunk Security Advisory SVD-2026-0603](https://advisory.splunk.com/advisories/SVD-2026-0603) - [watchTowr Labs - Why Use App-Level Auth When Every Database Has Auth? Splunk Enterprise CVE-2026-20253 Pre-Auth RCE](https://labs.watchtowr.com/why-use-app-level-auth-when-every-database-has-auth-splunk-enterprise-cve-2026-20253-pre-auth-rce/) - [watchTowr Labs - Proof-of-Concept Repository](https://github.com/watchtowrlabs/watchTowr-vs-Splunk-CVE-2026-20253/tree/main) - [CISA Known Exploited Vulnerabilities Catalog - CVE-2026-20253](https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-20253) Tags: CVE-2026-20253, Splunk, Remote Code Execution, Authentication Bypass, CISA KEV, PostgreSQL --- Source: [RadicalNotion.AI](https://radicalnotion.ai/blog/critical-splunk-enterprise-flaw-cve-2026-20253-under-active-exploitation-pre-auth-rce-via-postgresql-20260619125623). Licensed CC BY-NC 4.0; attribute RadicalNotion.AI and link the source page when you reuse this data.