Splunk Enterprise Vulnerability Exploited in Attacks Days After Disclosure

1. Executive summary

CVE-2026-20253 is a critical (CVSS 9.8) unauthenticated remote code execution flaw in Splunk Enterprise, triggered by missing authentication controls on the PostgreSQL sidecar service endpoint. The vulnerability affects Splunk Enterprise versions 10.2 before 10.2.4 and 10.0 before 10.0.7; Splunk released patches on 10 June 2026. Splunk's PSIRT confirmed limited in-the-wild exploitation on 18 June 2026, and CISA added the CVE to the Known Exploited Vulnerabilities (KEV) catalogue the same day, giving federal agencies until 21 June 2026 to remediate. WatchTowr has published a working PoC and full technical details, meaning weaponised exploitation is now broadly accessible. EMEA financial services firms running affected Splunk Enterprise versions — particularly SIEM/SOC deployments and any Splunk instance reachable from less-trusted networks — face immediate exposure and should treat this as a P1 patch item.

2. Regulatory framing

Article	Trigger (the fact in this item)	Practical impact
DORA Art. 17: ICT-related incident management process	Splunk PSIRT confirmed limited exploitation on 18 June 2026 — an ICT-related security incident has occurred against a third-party platform used by the firm.	Activate the firm's ICT-related incident management process; record, triage and evidence-handle any indicators of exploitation against Splunk instances.
DORA Art. 18: classification of ICT-related incidents and cyber threats	The vulnerability is being actively exploited (per CISA KEV listing) and constitutes a credible cyber threat to in-scope ICT systems.	Classify the event/threat against the firm's ICT incident classification taxonomy; ensure severity scoring reflects unauthenticated RCE potential.
DORA Art. 19: reporting of major ICT-related incidents to competent authorities	If exploitation against a firm's Splunk deployment causes a major ICT-related incident (service disruption, data impact, or downstream control failure), reporting obligations engage.	Pre-stage the initial notification template; assess whether the incident crosses the "major" threshold once impact is known.
DORA Art. 28: ICT third-party risk — general principles	Splunk Enterprise is an ICT third-party provider; the vulnerability is in a vendor-managed component (PostgreSQL sidecar).	Treat as a third-party risk event; ensure vendor risk register is updated and contractually-mandated notifications from Splunk are captured.
DORA Art. 29: preliminary assessment of ICT concentration risk	Splunk Enterprise is widely deployed across EMEA FS SIEM/SOC estates; concentration risk is material.	Re-evaluate concentration risk for Splunk Enterprise specifically; document substitutability and exit options.
DORA Art. 30: key contractual provisions with ICT third-party providers	Splunk is a material ICT third-party provider; vendor patch and notification obligations are contractually relevant.	Verify Splunk's contractual notification and support entitlements are being exercised; capture patch evidence per Art. 30 record-keeping.
NIS2 Art. 21(2)(d): supply chain security measures	The vulnerability sits in a third-party-supplied component (PostgreSQL sidecar) of a security-critical product used in the firm's supply chain.	Apply supply-chain security controls: confirm patch deployment, validate vendor attestation, and review any compensating controls.
NIS2 Art. 23: incident reporting obligations	Active exploitation confirmed; if a Splunk instance in scope of NIS2 is compromised and crosses the "significant" impact threshold, reporting obligations engage.	Pre-stage early warning / incident notification within NIS2 timelines once impact is known.
UK NIS 2018: UK Network and Information Systems Regulations — OES/RDSP duties	Splunk Enterprise is commonly used to deliver OES/RDSP monitoring and security functions; compromise could affect the OES/RDSP's own security posture.	OES/RDSP operators should treat Splunk as in-scope ICT supporting the regulated function and apply the same patching urgency.

3. Technical analysis & attack chain

Reach the PostgreSQL sidecar service endpoint. The attacker locates a Splunk Enterprise instance reachable over the network. The PostgreSQL sidecar service endpoint lacks authentication controls, so any network-reachable user can interact with it without credentials.
Invoke unauthenticated file operations. Through the unauthenticated endpoint, the attacker issues requests that create or truncate arbitrary files on the Splunk host.
Escalate file operation to remote code execution. WatchTowr demonstrated (technical details and PoC published two days after disclosure) that the arbitrary file create/truncate primitive can be chained into full unauthenticated RCE on the Splunk server.
Post-exploitation activity. The source material does not document specific post-exploitation tradecraft, tooling, persistence, lateral movement, or data access observed in the wild. Splunk PSIRT describes exploitation as "limited" with no public attribution to a named actor.

Vulnerability mechanism. The root cause is the absence of authentication on the PostgreSQL sidecar service endpoint. Splunk's own advisory states: "the PostgreSQL sidecar service endpoint lacks authentication controls, allowing any network-reachable user to invoke file operations without credentials." This is an authentication-bypass / missing-access-control class flaw, not a memory-corruption bug.

Affected versions (authoritative per Splunk advisory).

Splunk Enterprise 10.2 before 10.2.4 — vulnerable
Splunk Enterprise 10.0 before 10.0.7 — vulnerable
All other versions outside these branches are not described as affected in the source material; treat unconfirmed.

Patch availability. Splunk announced fixed releases on 10 June 2026. Fixed versions are 10.2.4 and 10.0.7 (and later).

Exploitation status. Splunk PSIRT became aware of limited exploitation in June 2026 and confirmed exploitation on 18 June 2026. CISA added CVE-2026-20253 to KEV on 18 June 2026 with a federal remediation deadline of 21 June 2026. This is the first Splunk CVE to appear on the CISA KEV catalogue.

Attribution. No threat actor has been publicly named in the source material. Any attribution should be treated as unconfirmed until Splunk PSIRT, CISA, or a named MITRE-tracked actor profile is published.

4. Mitigation & containment

P1 — within 24 hours

Patch Splunk Enterprise to a fixed release. Upgrade to 10.2.4 or later (10.x branch) or 10.0.7 or later (10.0 branch). This is the primary remediation; treat as the only fully-trusted fix.
Inventory and prioritise. Identify every Splunk Enterprise instance in the estate (search the CMDB, deployment inventories, and Splunk deployment server records). Flag any instance on 10.2.x < 10.2.4 or 10.0.x < 10.0.7 as P1.
Network exposure review. Identify whether the PostgreSQL sidecar service endpoint is reachable from untrusted networks (internet, partner networks, third-party access paths, jump hosts). If reachable, isolate immediately (firewall ACL, security group deny) until patched.
Restrict the sidecar endpoint at the network layer. Until patching completes, block inbound access to the PostgreSQL sidecar service port from anything other than known management sources. Confirm the listening port in your environment (default PostgreSQL is 5432/tcp, but verify against Splunk's deployment guide for your version).
Detection sweep. Hunt for evidence of unauthenticated file create/truncate activity on Splunk hosts and for unexpected child processes spawned by the Splunk service account.

P2 — within 72 hours

Validate patch deployment. Confirm Splunk services restarted cleanly post-upgrade; verify the build string reports the fixed version.
Review Splunk access logs and PostgreSQL sidecar logs for the period 10 June 2026 onward (disclosure date) for any unauthenticated or anomalous sessions, especially from external IPs.
Engage vendor (Splunk/Cisco) per contract. Confirm receipt of vendor security notifications and capture evidence per DORA Art. 30 record-keeping.
Re-assess concentration risk for Splunk Enterprise per DORA Art. 29; document substitutability and exit options.

P3 — within 7 days

Compensating controls. If any instance cannot be patched within 7 days, document the compensating control (network isolation, jump-host-only access, monitored WAF/IPS rule) and obtain risk acceptance in writing.
Tabletop / lessons-learned. Run a short incident-readiness exercise covering Splunk-as-third-party compromise scenarios; feed into DORA Art. 24 testing programme.
Threat intel subscription check. Ensure Splunk PSIRT alerts and CISA KEV feeds are ingested into the SOC and ticketed against the firm's vulnerability management process.

5. Indicators of compromise

No indicators of compromise available in the source material.

The source material does not provide specific attacker IPs, domains, file hashes, filenames, or post-exploitation tooling. Splunk PSIRT describes exploitation as "limited" and notes there is no publicly available information about the attacks themselves. WatchTowr's PoC is publicly available but is not, by itself, an IOC.

6. Detection

Insufficient indicators to author detection rules.

The source material does not contain distinctive strings, command-line flags, mutex names, scheduled-task names, filenames, registry keys, or hard-coded values from observed exploitation. Authoring a YARA or Sigma rule on the available material would require fabricating artefacts, which we will not do. Recommended compensating detection (not authored as a rule here):

Alert on any inbound network session to the PostgreSQL sidecar service endpoint originating from outside the known management allow-list.
Alert on file create/truncate events in Splunk install directories (e.g. $SPLUNK_HOME, $SPLUNK_DB) by processes other than the Splunk service account.
Alert on child processes spawned by the Splunk service account that are not part of the documented Splunk execution chain.

7. Sources

SecurityWeek — Splunk Enterprise Vulnerability Exploited in Attacks Days After Disclosure — https://www.securityweek.com/splunk-enterprise-vulnerability-exploited-in-attacks-days-after-disclosure/ — 19 June 2026
The Hacker News — Critical Splunk Enterprise Flaw Lets Attackers Run Code Without Authentication — https://thehackernews.com/2026/06/critical-splunk-enterprise-flaw-lets.html — June 2026
BSI Germany (CERT-Bund) — [NEU] [hoch] Splunk Enterprise: Mehrere Schwachstellen — https://wid.cert-bund.de/portal/wid/securityadvisory?name=WID-SEC-2026-1877 — June 2026

8. Adverse Trace position

Severity: Critical. CVSS 9.8, unauthenticated RCE, KEV-listed, PoC public, exploitation confirmed by the vendor. This combination places CVE-2026-20253 in the highest-priority tier for EMEA financial services. Splunk Enterprise is a foundational SIEM/SOC and log-analytics platform across the sector; the missing-authentication root cause on a network-reachable endpoint means any unpatched, network-reachable instance is a viable initial-access vector. Client impact: firms running affected versions should assume exposure until patched and isolated, and should run a focused hunt for evidence of pre-patch exploitation. Next steps: Adverse Trace will (a) monitor Splunk PSIRT and CISA for any named-actor attribution or additional IOCs and update this advisory, (b) re-test detection coverage once concrete IOCs emerge, and (c) incorporate the vulnerability into client DORA Art. 24 testing and third-party-risk reviews.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.