• Severity: CVSS 9.8 (Critical) - CWE-306, Missing Authentication for Critical Function
  • Affected: Splunk Enterprise 10.0.0-10.0.6 and 10.2.0-10.2.3; Splunk Enterprise on AWS is vulnerable out of the box
  • Patched: June 10, 2026 · Exploitation: Active - first exploitation activity observed June 15, 2026

Introduction

On June 10, 2026, Splunk (now part of Cisco) disclosed CVE-2026-20253, a critical vulnerability in the PostgreSQL sidecar service component of Splunk Enterprise. The advisory was classified under CWE-306 (Missing Authentication for Critical Function) and assigned a CVSS v3.1 score of 9.8, with a vector of AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H the trifecta of no authentication, no user interaction, and full impact across confidentiality, integrity, and availability.

The PostgreSQL sidecar is a helper component introduced in Splunk version 10 that manages database backup and recovery operations. It exposes internal API endpoints for these operations, and on certain deployment types those endpoints are reachable by any network-connected user. The root cause is disarmingly simple: the sidecar performs no authentication of its own. Any credential, including empty ones, is accepted.

Splunk Cloud Platform is not affected because Splunk Cloud does not use PostgreSQL sidecars. Splunk Enterprise versions 9.4 and earlier are also not affected, as the sidecar component was introduced in version 10. Organizations running on-premises Splunk Enterprise on Linux/AWS are the primary population at risk.

This is not an edge-case misconfiguration issue. A public PoC was released two days after disclosure, and active exploitation was reported within five days. If you are running a vulnerable version with the sidecar enabled, treat this as a fire drill.

What Happened

Splunk Enterprise includes a PostgreSQL sidecar service (splunk-postgres) deployed under /opt/splunk/var/run/supervisor/pkg-run/. This Go binary listens on localhost port 5435 and exposes several HTTP API endpoints, most notably /v1/postgres/recovery/backup and /v1/postgres/recovery/restore for database backup and restore operations.

The problem: the Splunk web application (listening on port 8000, reachable from the network) proxies requests transparently to this internal service. What was designed to be localhost-only becomes network-accessible through Splunk’s own proxy layer. And once the request reaches the sidecar, it performs no authentication at all. Whatever username is sent in the HTTP Basic Authorization header is simply forwarded as the -U argument to pg_dump or pg_restore. The sidecar delegates credential validation to PostgreSQL, which on an attacker-controlled host will accept anything you configure it to accept.

Researchers Piotr Bazydlo (@chudyPB) and Yordan Ganchev of watchTowr Labs published their full technical analysis on June 12, 2026, demonstrating that what Splunk described as “arbitrary file creation and truncation” is in fact a chainable pre-auth RCE. The exploit chain involves six distinct stages and abuses legitimate PostgreSQL functionality at every step, no memory corruption, no exotic primitives, just a cascade of missing checks and overly trusting components.

The vulnerability was originally discovered by Alex Hordijk (hordalex), credited in the Splunk advisory.

At time of writing, a public PoC/detection artifact generator is available on GitHub (from watchTowr Labs) and exploitation activity was observed starting June 15, 2026. The severity is no longer theoretical.

Attack Sequence

The full RCE chain is detailed in watchTowr Labs’ writeup (linked in References). Here is how the stages connect at a high level.

Reaching the internal service. The attacker sends HTTP requests to the Splunk web interface (/en-US/splunkd/__raw/v1/postgres/recovery/backup). The web application forwards these to the internal sidecar service on port 5435. Port 5435 was bound to localhost, but the proxy makes it reachable from anywhere that can talk to port 8000.

Bypassing authentication. The recovery endpoints appear to expect HTTP Basic credentials. In practice the sidecar accepts anything, including an empty Authorization: Basic Og== header (which decodes to a blank username and password). The username supplied is passed straight to pg_dump via -U; the sidecar never checks it. This is the core CWE-306 finding.

Getting arbitrary file write. The backupFile parameter is passed directly to pg_dump as the output path with no directory constraints. A path traversal sequence (e.g., ../../../../../../tmp/poc) creates an empty file at any location writable by the Splunk service account. The file is empty at this stage because the attacker has no credentials for the local PostgreSQL instance, but that changes in the next steps.

Redirecting pg_dump to an attacker-controlled database. PostgreSQL’s documentation notes that the dbname argument can contain a full connection string, and that connection string parameters override conflicting command-line options. The sidecar hardcodes -h localhost, but supplying hostaddr=attacker-controlled-host in the database parameter overrides it. Splunk reaches out to the attacker’s PostgreSQL server, which is configured to accept passwordless connections and returns a dump of the attacker’s own database, with real content.

Authenticating to Splunk’s local database. The /restore endpoint uses pg_restore with the same parameter passing pattern. Splunk stores PostgreSQL credentials in a .pgpass file at /opt/splunk/var/packages/data/postgres/.pgpass. By injecting passfile=/opt/splunk/var/packages/data/postgres/.pgpass into the database connection string, the attacker instructs pg_restore to authenticate to the local Splunk PostgreSQL instance using those stored credentials.

Turning restore into code execution. A pg_restore operation replays the SQL contained in a backup file. The attacker crafts a malicious database dump containing a function that calls lo_export a PostgreSQL built-in that writes a BLOB from the database to the filesystem. When the restore operation runs, lo_export writes attacker-controlled content to any file the Splunk user can write to. The attacker targets /opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py, a Python script that Splunk executes on a recurring schedule. Overwriting it with a malicious payload results in code execution under the Splunk service account.

Full pre-authentication RCE, zero credentials required, from a single reachable HTTP endpoint.

Why This Is Especially Dangerous

The CVSS score tells part of the story. The deployment context tells the rest.

  • Splunk is the security stack. Splunk Enterprise is commonly used as the SIEM at the center of security operations. A compromised Splunk instance gives an attacker read access to aggregated logs, security alerts, authentication events, and incident response data from across the entire environment, the full picture of what defenders can and cannot see.
  • Enabled by default on AWS. On Splunk Enterprise deployments hosted on AWS, the PostgreSQL sidecar is installed and enabled out of the box. Those instances are vulnerable immediately after deployment on an affected version, with no configuration required.
  • Credentials stored on disk. The .pgpass file at a predictable path stores the postgres_admin credential in cleartext. The exploit chain relies on this, but so does any post-compromise attacker who gets read access to the filesystem through any other means.
  • No authentication, no user interaction, low complexity. The CVSS vector is as clean as it gets for remote exploitation. There is no phishing step, no session required, no timing window.
  • Active exploitation in the wild. Exploitation activity was observed starting June 15, 2026, five days after disclosure. A public PoC is available on GitHub. Opportunistic scanning and exploitation is a near-certainty for any internet-facing instance running an affected version.
  • Lateral movement amplifier. Splunk commonly integrates with Active Directory, cloud platforms, endpoint security tools, databases, and network infrastructure. A Splunk foothold gives an attacker visibility into the environment and a pivot point into connected systems.

Affected Versions

BranchVulnerable VersionsFix Version
Splunk Enterprise 10.210.2.0 - 10.2.310.2.4
Splunk Enterprise 10.010.0.0 - 10.0.610.0.7
Splunk Enterprise 10.4Not affected10.4.0 (baseline)
Splunk Enterprise 9.4 and earlierNot affectedN/A
Splunk Cloud PlatformNot affectedN/A

The PostgreSQL sidecar component was introduced in Splunk version 10. Any version prior to 10.0 is not affected. Splunk Cloud Platform does not use PostgreSQL sidecars and is not affected. Splunk confirmed this and removed Cloud Platform from the advisory scope on June 12, 2026.

Mitigations

1. Patch immediately. Upgrade Splunk Enterprise to 10.2.4 (for 10.2.x branches) or 10.0.7 (for 10.0.x branches). This is the only complete fix. The Splunk security advisory SVD-2026-0603 is the authoritative source for update instructions.

2. Disable the PostgreSQL sidecar service (if immediate patching is not possible). Add the following stanza to $SPLUNK_HOME/etc/system/local/server.conf:

[postgres]
disabled = true

Restart Splunk Enterprise for this to take effect. Note: disabling the sidecar will break Edge Processor, OpAmp, and SPL2 data pipelines on that instance. Core search, indexing, and dashboard functionality are not affected. Do not apply this workaround if those pipeline features are in active use.

3. Restrict network access to Splunk management interfaces. The exploit chain reaches the sidecar through Splunk’s web interface on port 8000. Limiting which hosts can reach port 8000 reduces exposure significantly. Splunk management interfaces should not be reachable from the public internet or from untrusted network segments. Enforce this at the network perimeter or host-based firewall level.

4. Isolate Splunk infrastructure. Network segmentation that prevents untrusted hosts from reaching the Splunk web interface effectively neutralizes remote exploitation even before patching. Treat any Splunk instance with external or broad internal network access as urgent priority.

5. Audit and rotate credentials. The .pgpass file at /opt/splunk/var/packages/data/postgres/.pgpass stores PostgreSQL credentials used by the exploit chain. If you suspect prior exposure, rotate those credentials along with any other secrets accessible to the Splunk service account (API tokens, integration keys, service account passwords).

6. Verify file integrity of Splunk application scripts. The exploit targets /opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py for code execution. Verify the integrity of Python scripts under /opt/splunk/etc/apps/ and monitor for unexpected modifications.

Indicators of Compromise

Splunk has not published official IoCs for CVE-2026-20253. The following behavioural hunting checklist is based on the publicly known attack chain. Update this list as the advisory evolves.

In Splunk and web access logs:

  • HTTP POST requests to /en-US/splunkd/__raw/v1/postgres/recovery/backup or /restore from unexpected sources
  • Requests containing path traversal sequences (../) in the backupFile parameter value
  • Requests where the database field contains PostgreSQL connection string keywords: hostaddr=, passfile=, dbname=, port=
  • Authorization: Basic Og== (empty credentials) in request headers to the above endpoints
  • Repeated 200 responses to unauthenticated backup/restore requests

On the Splunk server filesystem:

  • Unexpected files created in /tmp/ or outside the sidecar working directory (check /opt/splunk/var/run/supervisor/pkg-run/)
  • Modifications to Python scripts under /opt/splunk/etc/apps/, particularly splunk_secure_gateway/bin/ssg_enable_modular_input.py
  • Database dump files (.dump, .sql, .Fc extension) in unexpected filesystem locations
  • Unexpected files in the Splunk webroot (/opt/splunk/share/splunk/search_mrsparkle/exposed/)

In process and network logs:

  • pg_dump or pg_restore processes spawned by the Splunk service account with unusual arguments
  • Outbound network connections from the Splunk server to external PostgreSQL servers (port 5432) - this indicates the attacker redirected pg_dump to their own database
  • Unexpected Python script execution not associated with a known user or scheduled search
  • Connections to port 5435 that originate from outside the Splunk service account context

Detection tooling: watchTowr Labs released a Detection Artifact Generator (DAG) on GitHub that probes whether the /v1/postgres/recovery/backup endpoint responds without credentials. A 400 response indicates vulnerability; a 401 indicates the instance is patched or protected. A Nuclei template for detection is also publicly available via the 0xBlackash/CVE-2026-20253 GitHub repository.

This post reflects what is publicly known as of June 18, 2026. Check the Splunk advisory (SVD-2026-0603) for updated guidance, official IoC releases, and any additional mitigations as the situation develops.

References