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)
- Initial access — unauthenticated network reachability. Attacker reaches the Splunk Enterprise PostgreSQL sidecar service over the network with no credentials.
- Arbitrary file write via
/v1/postgres/recovery/backup. Attacker connects to an attacker-controlled PostgreSQL database and uses the/backupendpoint to dump its contents to an arbitrary file path on the Splunk host. - Restore with credential file via
/v1/postgres/recovery/restore. Attacker invokes the/restoreendpoint, supplying apassfileargument that points to/opt/splunk/var/packages/data/postgres/.pgpass— the local PostgreSQL credential file containing thepostgres_adminpassword. This authenticates the restore against the local Splunk PostgreSQL instance. - Attacker-controlled SQL execution. SQL statements embedded in the restored dump are executed by Splunk's local PostgreSQL instance.
- Controlled file write via
lo_export. Attacker defines a PostgreSQL function that callslo_exportto extract a BLOB and write attacker-controlled content to a file on the Splunk filesystem. - 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/backupandPOST /v1/postgres/recovery/restoreon the Splunk Enterprise PostgreSQL sidecar. - Credential file referenced:
/opt/splunk/var/packages/data/postgres/.pgpass(containspostgres_adminpassword). - 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 thejsonpicklePython 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
.pgpassfile at/opt/splunk/var/packages/data/postgres/.pgpassfor unexpected modification timestamps or content; rotate thepostgres_adminpassword if any anomalous activity is observed. - Audit file integrity of
/opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.pyand 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/backupand/v1/postgres/recovery/restorefrom 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
jsonpickledeserialization 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.
Published via PulseTrace — Adverse Trace threat intelligence.