~/f4n6 $ grep -r "Critical Splunk Enterprise Flaw Lets Attackers Run Code Without Authentication" ./investigations/ --include="*.md"

Critical Splunk Enterprise Flaw Lets Attackers Run Code Without Authentication

Jeff Davies 13 Jun 2026 6 min read

1. Executive summary

Splunk has disclosed CVE-2026-20253, a critical (CVSS 9.8) flaw in the Splunk Enterprise PostgreSQL sidecar service that allows an unauthenticated, network-reachable attacker to perform arbitrary file operations and achieve remote code execution (RCE). The vulnerability is not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalogue and EPSS exploitation probability is reported at 0%, but watchTowr Labs has published a full technical exploit chain and the endpoints are well-known. Splunk Enterprise deployments below 10.0.7 / 10.2.4 (and the corresponding 9.x branches) are affected; Splunk Cloud is not affected. Splunk is widely deployed across EMEA financial services for SIEM and log analytics, meaning unpatched on-prem Splunk Enterprise instances represent a high-impact initial-access and lateral-movement risk for EMEA FS firms.

2. Regulatory framing

Article Trigger (the fact in this item) Practical impact
DORA Art. 28 (ICT third-party risk — general principles) Splunk Enterprise is an ICT third-party provider commonly used by FS firms for SIEM/log analytics. Firms must ensure their ICT third-party risk framework covers Splunk and that this CVE is tracked in vendor-risk records.
DORA Art. 30 (key contractual provisions with ICT third-party providers) Splunk has issued security updates; contractual notification and remediation obligations apply. Confirm vendor notification has been received and that patching SLAs in ICT contracts are being honoured.
DORA Art. 29 (preliminary assessment of ICT concentration risk) Splunk is a concentrated SIEM vendor across many EMEA FS firms. Assess concentration exposure: identify which critical functions depend on Splunk and plan for vendor-substitutability.
NIS2 Art. 21(2)(d) (supply chain security measures) The vulnerability resides in a widely-deployed third-party product with a published pre-auth RCE chain. Apply the security patch as part of supply-chain security measures and verify handling of the affected components.
DORA Art. 24 (digital operational resilience testing — general requirements) Splunk is in scope of resilience testing programmes (vulnerability management, pen-test scope). Include the patched Splunk build in test scope and re-baseline any assumptions about Splunk attack surface.
UK NIS 2018 (OES/RDSP duties) Splunk is commonly used by operators of essential services and relevant digital service providers. Ensure OES/RDSP entities patch affected Splunk Enterprise instances and reflect the change in security-update management.

DORA Art. 17, 18, 19 and NIS2 Art. 23 are engaged only on confirmed exploitation or major incident; they are not directly triggered by the advisory itself.

3. Technical analysis & attack chain

Vulnerable component: Splunk Enterprise PostgreSQL sidecar service endpoint (no authentication controls).

Affected versions (per Splunk advisory and GHSA-3crw-7xg9-fpxg)

  • Splunk Enterprise: below 10.2.4, below 10.0.7, below 9.4.12, below 9.3.13
  • Splunk Cloud Platform: below 10.3.2512.12, 10.2.2510.14, 10.1.2507.22, 9.3.2411.132
  • Splunk Secure Gateway: below 3.10.6, 3.9.20, 3.8.67
  • Splunk Enterprise 10.4: not affected
  • Splunk Cloud: not affected (Postgres sidecars not used)

Fixed versions: Splunk Enterprise 10.0.7 and 10.2.4 (and corresponding 9.x back-ports).

Attack chain (CVE-2026-20253)

  1. Initial access — unauthenticated network reachability. Attacker reaches the Splunk Enterprise PostgreSQL sidecar service over the network with no credentials.
  2. Arbitrary file write via /v1/postgres/recovery/backup. Attacker connects to an attacker-controlled PostgreSQL database and uses the /backup endpoint to dump its contents to an arbitrary file path on the Splunk host.
  3. Restore with credential file via /v1/postgres/recovery/restore. Attacker invokes the /restore endpoint, supplying a passfile argument that points to /opt/splunk/var/packages/data/postgres/.pgpass — the local PostgreSQL credential file containing the postgres_admin password. This authenticates the restore against the local Splunk PostgreSQL instance.
  4. Attacker-controlled SQL execution. SQL statements embedded in the restored dump are executed by Splunk's local PostgreSQL instance.
  5. Controlled file write via lo_export. Attacker defines a PostgreSQL function that calls lo_export to extract a BLOB and write attacker-controlled content to a file on the Splunk filesystem.
  6. RCE via Python script overwrite. Attacker overwrites a Python script Splunk routinely executes — for example /opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py — with a malicious payload. Splunk's normal execution of that script yields code execution as the Splunk service account.

Technical specifics for defenders

  • Endpoints exploited: POST /v1/postgres/recovery/backup and POST /v1/postgres/recovery/restore on the Splunk Enterprise PostgreSQL sidecar.
  • Credential file referenced: /opt/splunk/var/packages/data/postgres/.pgpass (contains postgres_admin password).
  • PostgreSQL primitive abused: lo_export (extract BLOB to file).
  • Target file for RCE pivot: /opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py (and any other Python script Splunk periodically executes).
  • Authentication: None required — the sidecar endpoint lacks authentication controls.
  • CWE: CWE-306 (Missing Authentication for Critical Function).
  • Related (separate) issue in same Splunk advisory: A low-privileged (non-admin/non-power) user can also achieve RCE through the Splunk Secure Gateway app via unsafe deserialization of App Key Value Store (KV Store) data through the jsonpickle Python library. This is a distinct issue from CVE-2026-20253 but is fixed by the same version bumps.

Unconfirmed / single-sourced claims. The technical detail above is sourced from watchTowr Labs' public write-up and Splunk's own advisory. No in-the-wild exploitation has been observed at time of publication; treat any future claim of mass exploitation as unconfirmed until corroborated by vendor or CISA KEV listing.

4. Mitigation & containment

P1 — within 24 hours

  • Patch Splunk Enterprise to 10.0.7 or 10.2.4 (or the corresponding 9.4.12 / 9.3.13 back-port for 9.x deployments). Splunk Cloud requires no customer action.
  • Restrict network exposure of the PostgreSQL sidecar service. The endpoint must not be reachable from untrusted networks; bind it to localhost or a dedicated management VLAN and firewall it off from the internet and from general corporate subnets.
  • Inventory and isolate any Splunk Enterprise instance below the fixed versions until patched; treat the Splunk host as a high-value asset and review for indicators of pre-patch exploitation (see Section 5).

P2 — within 72 hours

  • Audit the .pgpass file at /opt/splunk/var/packages/data/postgres/.pgpass for unexpected modification timestamps or content; rotate the postgres_admin password if any anomalous activity is observed.
  • Audit file integrity of /opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py and other Splunk-executed Python scripts for unexpected modification timestamps or content.
  • Rotate any credentials, API tokens or service-account secrets stored on or accessible from the Splunk host.
  • Review web/proxy logs for traffic to /v1/postgres/recovery/backup and /v1/postgres/recovery/restore from non-Splunk source IPs.

P3 — within 7 days

  • Validate Splunk Secure Gateway version (3.10.6 / 3.9.20 / 3.8.67 or later) and apply the jsonpickle deserialization fix delivered in the same advisory.
  • Re-baseline pen-test scope to include the patched Splunk build and confirm DORA Art. 24 testing assumptions.
  • Vendor-risk record update: record CVE-2026-20253 in the Splunk vendor-risk file and confirm contractual remediation obligations under DORA Art. 30 have been satisfied.

5. Indicators of compromise

Type Value Confidence Source
url /v1/postgres/recovery/backup high watchTowr Labs / Splunk advisory
url /v1/postgres/recovery/restore high watchTowr Labs / Splunk advisory
filepath /opt/splunk/var/packages/data/postgres/.pgpass high watchTowr Labs
filepath /opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py high watchTowr Labs
user postgres_admin (PostgreSQL role) high watchTowr Labs
url       /v1/postgres/recovery/backup
url       /v1/postgres/recovery/restore
filepath  /opt/splunk/var/packages/data/postgres/.pgpass
filepath  /opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py
user      postgres_admin

6. Detection

rule AT_Splunk_CVE_2026_20253_Artifacts
{
    meta:
        author      = "Adverse Trace"
        date        = "2026-06-13"
        description = "Detects filesystem artefacts and string indicators associated with exploitation of CVE-2026-20253 in Splunk Enterprise PostgreSQL sidecar"
        reference   = "https://thehackernews.com/2026/06/critical-splunk-enterprise-flaw-lets.html"
        cve         = "CVE-2026-20253"
    strings:
        $pgpass_path     = "/opt/splunk/var/packages/data/postgres/.pgpass"
        $ssg_script      = "ssg_enable_modular_input.py"
        $ep_backup       = "/v1/postgres/recovery/backup"
        $ep_restore      = "/v1/postgres/recovery/restore"
        $lo_export       = "lo_export"
        $pgpass_user     = "postgres_admin"
    condition:
        any of them
}
title: Splunk Enterprise CVE-2026-20253 PostgreSQL Sidecar Endpoint Access
id: 8a3f1c2e-2026-06-13-100
status: experimental
description: Detects HTTP requests to the vulnerable Splunk Enterprise PostgreSQL sidecar endpoints exploited in CVE-2026-20253
author: Adverse Trace
date: 2026-06-13
references:

  - https://thehackernews.com/2026/06/critical-splunk-enterprise-flaw-lets.html
logsource:
  category: webserver
  product: splunk
detection:
  selection_paths:
    cs-uri-path:

      - "/v1/postgres/recovery/backup"
      - "/v1/postgres/recovery/restore"
  condition: selection_paths
level: critical
tags:

  - cve-2026-20253
  - attack.initial_access
  - attack.t1190

CVE assessment

1 referenced CVE — 1 critical (CVSS ≥ 9.0)

CVE CVSS Exploited EPSS Summary
CVE-2026-20253 9.8 Critical 0% In Splunk Enterprise versions below 10.2.4 and 10.0.7, and Splunk Cloud Platform versions below 10.4.2604.3 and 10.2.2510.14, a…

7. Sources

  • The Hacker News — Critical Splunk Enterprise Flaw Lets Attackers Run Code Without Authentication — https://thehackernews.com/2026/06/critical-splunk-enterprise-flaw-lets.html — 2026-06-13
  • GitHub Security Advisories — GHSA-3crw-7xg9-fpxg — https://github.com/advisories/GHSA-3crw-7xg9-fpxg — 2026-06
  • BSI Germany (CERT-Bund) — WID-SEC-2026-1877: Splunk Enterprise — Mehrere Schwachstellen — https://wid.cert-bund.de/portal/wid/securityadvisory?name=WID-SEC-2026-1877 — 2026-06

8. Adverse Trace position

Severity: Critical (CVSS 9.8, CWE-306). The vulnerability is pre-authentication, network-reachable, and trivially escalates to RCE via a well-documented chain; however, it is not currently in CISA KEV and EPSS exploitation probability is 0%, indicating no confirmed in-the-wild exploitation at time of publication. Client impact: any EMEA FS firm running on-prem Splunk Enterprise below the fixed versions and exposing the PostgreSQL sidecar beyond a trusted management network is at material risk of initial access and lateral movement. Next steps: Adverse Trace will (1) push this advisory to all EMEA FS clients with a 24-hour patching SLA, (2) assist with Splunk-side containment and post-exploitation forensics on request, and (3) re-issue this advisory immediately if CISA KEV listing or active in-the-wild exploitation is confirmed.


Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.

Post this to LinkedIn
Formatting is converted automatically — headings, bullets, a link back & hashtags. Paste straight in.
J
Jeff Davies