PATCH NOW: CISA Confirms Hackers Are Actively Exploiting a Critical Splunk Flaw

AT A GLANCE

A table summarizing a Splunk flaw, listing details such as CVE ID, CVSS score, CWE, affected versions, fix, patch release date, exploited instances by hackers, and notable tags like "CISA," "WatchTowr," and "Shadowserver.

What Is CVE-2026-20253 and What Happened?

On June 10, 2026, Cisco-owned Splunk disclosed CVE-2026-20253 — a critical vulnerability in Splunk Enterprise, the world’s most widely deployed Security Information and Event Management (SIEM) platform. The flaw earned a CVSS score of 9.8 out of 10 — the highest possible for network-exploitable vulnerabilities — and it belongs to one of the most dangerous vulnerability classes in existence: missing authentication for a critical function.

Within two days, on June 12, security research firm WatchTowr Labs published a detailed technical write-up and a working proof-of-concept (PoC) exploit demonstrating that the file-write primitive could be escalated all the way to full, pre-authentication remote code execution. Six days after that PoC went public, on June 18, Splunk confirmed active exploitation in the wild. CISA added CVE-2026-20253 to its Known Exploited Vulnerabilities catalog the same day — making it the first Splunk vulnerability in history to appear on that list.

ACTIVE EXPLOITATION CONFIRMED. Splunk PSIRT and CISA both confirmed active in-the-wild exploitation on June 18, 2026 — just 6 days after a public working exploit was released. There is no patch window left. If you are running a vulnerable Splunk version, treat your system as potentially compromised already.

CVE-2026-20253 is not a vulnerability in a web server or a peripheral database. Splunk Enterprise is the SIEM — the system where all of your organization’s security telemetry converges. Compromising Splunk with code execution access means an attacker doesn’t just own one server. They own your visibility. — APOLOCybersecurity

The Root Cause: What Went Wrong

The vulnerability exists in Splunk Enterprise’s PostgreSQL Sidecar Service — a background helper component introduced in Splunk Enterprise v10 to support internal database operations. The sidecar exposes two HTTP endpoints used for backup and recovery operations:

/v1/postgres/recovery/backup
/v1/postgres/recovery/restore

Under normal conditions, these endpoints are only accessible on localhost (127.0.0.1:5435) — meaning external users shouldn’t be able to reach them. But Splunk’s main web interface (port 8000) acts as a reverse proxy and relays requests to these internal endpoints. This creates a critical gap: a service assumed to be internal becomes reachable from outside the system through the proxy path.

The second failure: the endpoints accept any HTTP Basic Authorization header — including a completely blank one. The header Authorization: Basic Og== (which decodes to a blank username and a blank password) is accepted and processed normally. No valid credentials are required at any step. The sidecar service performs no authentication of its own.

“Neither the sidecar’s local API nor the proxy path performs any authentication check. Any request that reaches Splunk’s main web port, including from an attacker with zero credentials, is forwarded straight to a service that can read, write, and truncate files on disk.” — protego.me

How the Attack Works: Step-by-Step Exploit Chain

WatchTowr Labs demonstrated that this vulnerability escalates from a simple file-write bug to full remote code execution through a chain of five steps — all without any credentials or user interaction.

▸ Step 1 — Remote Access via Proxy (No Credentials Needed)

The attacker sends an HTTP POST request to Splunk’s web interface on port 8000. The request targets the path /en-US/splunkd/__raw/v1/postgres/recovery/backup. Splunk Web proxies this request directly to the PostgreSQL sidecar on localhost:5435 — no authentication check occurs at any point in this relay.

▸ Step 2 — Arbitrary File Creation via Path Traversal

The backup endpoint accepts a backupFile parameter specifying the output path for pg_dump. Because this parameter is not constrained to a safe directory, the attacker can supply a path-traversal sequence (e.g., ../../tmp/evil) and have pg_dump write a file to any location on the filesystem that the Splunk service account can write to.

▸ Step 3 — Write Attacker-Controlled Content via lo_export

The attacker abuses PostgreSQL’s lo_export function — a feature designed to export a Binary Large Object (BLOB) from the database and save it as a file on the server. By inserting a malicious BLOB into the PostgreSQL instance and then exporting it to a target path via lo_export, the attacker can write arbitrary attacker-controlled content to any writable location — not just empty files.

▸ Step 4 — Steal Credentials from .pgpass

The exploit chain also accesses PostgreSQL’s .pgpass file, which stores database credentials in plaintext. These credentials can be harvested for follow-on lateral movement within the environment.

▸ Step 5 — Remote Code Execution via Python Script Overwrite

Splunk executes Python scripts for multiple internal functions — search operations, secure gateway processing, and application management. The attacker overwrites one of these Python scripts with malicious code using the arbitrary file write primitive. On Splunk’s next execution cycle, the malicious script runs in the context of the Splunk service account, achieving full remote code execution on the server.

WatchTowr’s PoC demonstrated the full chain. Indicators of compromise include: unexpected files in /tmp/ or /opt/splunk/var/run/supervisor/pkg-run/, overwritten Python scripts in the splunk_secure_gateway app, the presence of files like /opt/splunk/share/splunk/search_mrsparkle/exposed/watchTowr.txt, and unusual outbound connections from Splunk to unknown PostgreSQL servers.

Why Splunk Makes This Uniquely Dangerous

Most vulnerabilities, however severe, affect one system. A compromised web server loses that server’s data. A compromised endpoint loses that device. CVE-2026-20253 is different — because of what Splunk is and what it sees.

Splunk Is the Nerve Center of Your Security Stack

In most enterprise environments, Splunk ingests data from:

Endpoint Detection and Response (EDR) tools — every process, file, and network event on every endpoint
Firewall logs — all inbound and outbound network traffic
Active Directory — every authentication attempt, user creation, privilege escalation, and logon event
Cloud trails — AWS CloudTrail, Azure Monitor, GCP audit logs
SIEM alerts — the dashboard executives look at when they ask ‘are we under attack?’
Email security — phishing attempts, malicious attachments
Vulnerability scanner output — your complete list of known weaknesses

When an attacker achieves RCE on Splunk, they don’t just own one server. They gain access to all of this data simultaneously — a complete map of your environment, your detection capabilities, your known vulnerabilities, and your incident response processes.

They Can Blind Your Entire Security Team

The most dangerous capability the flaw provides isn’t data exfiltration — it’s the ability to delete or corrupt log data. An attacker with RCE on Splunk can:

Erase evidence of their own intrusion from your SIEM — cleaning logs retroactively
Corrupt the integrity of forensic data you would rely on during incident response
Disable alerting rules so that follow-on attacks don’t trigger any notifications
Modify dashboards and reports to hide anomalous activity from your security team

“Because the bug allows log tampering, do not treat clean local logs as proof of safety — corroborate with upstream telemetry.” — ZeroDay Hub. If CVE-2026-20253 has been exploited against your Splunk instance, your own logs cannot be trusted.

AWS Deployments Are Especially Exposed

Splunk Enterprise deployments on Amazon Web Services have the PostgreSQL sidecar service enabled by default. On-premises installations may require explicit enabling of the service, but AWS-hosted Splunk instances are vulnerable in their default configuration. If your organization runs Splunk on AWS, treat this as your highest-priority patching action today.

The Full Timeline

A table lists six cybersecurity events in June 2026, including Splunk advisories, CISA actions, and attacks by hackers linked to WatchTower Labs and Shadowsaver, highlighting critical vulnerabilities, published advisories, and exploitation notices.

Additional CVEs in the Same Advisory Batch

CVE-2026-20253 was not published alone. Splunk’s June 10 advisory batch also included three additional vulnerabilities that security teams must address alongside the PostgreSQL sidecar flaw:

A table listing four CVEs with their CVSS scores, affected components, exploit descriptions, and potential exploiters. The highest score is 9.8 (Critical) for a PostgreSQL Sidecar vulnerability that hackers could exploit, including a Splunk flaw.

Patching CVE-2026-20253 alone is not enough. Apply all fixes from the June 10, 2026 advisory batch (SVD-2026-0603) simultaneously. CVE-2026-20251 in particular is also rated high severity and enables RCE with a low-privilege account.

Resolution: What Has Been Done

Vendor Response — Splunk / Cisco

Patches released June 10, 2026 in Splunk Enterprise 10.0.7, 10.2.4, and 10.4.0
Splunk PSIRT confirmed active exploitation on June 18, 2026 and strongly urged immediate upgrade
Splunk confirmed Splunk Cloud Platform is not affected by CVE-2026-20253
Workaround published: disabling the PostgreSQL sidecar service removes the attack surface — but breaks Edge Processor, OpAmp, and SPL2 data pipelines if in use

Government Response — CISA

June 18, 2026: Added CVE-2026-20253 to the Known Exploited Vulnerabilities (KEV) catalog — the first Splunk entry ever
Issued Binding Operational Directive (BOD) 26-04 requiring all Federal Civilian Executive Branch agencies to remediate by June 21, 2026
CISA also mandated Forensics Triage Requirements — organizations must assess whether systems may have been compromised prior to patching
CISA recommendation for private sector: treat this with the same urgency as federal agencies — attackers do not respect that boundary

Research Community Response

WatchTowr Labs (Piotr Bazydlo): Published full technical PoC on June 12, 2026
Shadowserver: Tracking 1,400+ internet-exposed Splunk instances globally
SOCRadar, Zscaler ThreatLabz, Orca Security, Picus Security: All published technical analyses and detection guidance
Hudson Rock and Kevin Beaumont: Validated exploitation evidence independently

Splunk Cloud Platform customers: You are NOT affected by CVE-2026-20253 specifically. However, review the full SVD-2026-0603 advisory — CVE-2026-20251, CVE-2026-20204, and CVE-2026-20258 may still apply to your environment.

What Your Organization Must Do — Complete Action Plan

Immediate Actions (Do These Today)

Identify all Splunk Enterprise instances — create a complete inventory of every Splunk Enterprise deployment, paying special attention to AWS-hosted instances where the PostgreSQL sidecar is enabled by default
Upgrade immediately to Splunk Enterprise 10.0.7, 10.2.4, or 10.4.0 (or later) — this is the only complete fix; there is no partial mitigation that eliminates all risk
Terminate all active administrative and SSL VPN sessions on Splunk — session hijacking may have already occurred on vulnerable systems
Rotate all credentials stored in or accessible from Splunk — service accounts, API keys, database credentials, and any secrets stored in Splunk’s KV Store

If You Cannot Patch Immediately

Disable the PostgreSQL sidecar service — add the following to $SPLUNK_HOME/etc/system/local/server.conf and restart Splunk (CAUTION: this breaks Edge Processor, OpAmp, and SPL2 pipelines if in use)
Block external access to the PostgreSQL sidecar endpoints — add reverse proxy or WAF rules to block POST requests to /v1/postgres/recovery/backup and /v1/postgres/recovery/restore
Remove Splunk Web from direct internet exposure — restrict management interfaces to trusted administrative networks only
Implement network segmentation between user subnets and Splunk infrastructure

Detection & Threat Hunting

Because CVE-2026-20253 enables log tampering, clean local Splunk logs cannot be treated as proof of no compromise. Corroborate with upstream telemetry from other sources:

Check for unexpected files in /tmp/ and /opt/splunk/var/run/supervisor/pkg-run/ on Splunk hosts
Look for modified or overwritten Python scripts in the splunk_secure_gateway app directory
Hunt for the presence of /opt/splunk/share/splunk/search_mrsparkle/exposed/watchTowr.txt — a known WatchTowr PoC artifact
Monitor for unusual outbound connections from Splunk to unknown PostgreSQL servers
Review reverse proxy, WAF, and firewall logs for unusual POST activity directed at Splunk sidecar-related service paths
Check EDR telemetry for anomalous child processes spawned by Splunk services that don’t match normal administrative workflows
Review Active Directory and domain controller logs for unusual authentication events originating from Splunk server IP addresses

A security vulnerability executive summary for the Splunk flaw in Splunk Enterprise’s PostgreSQL, detailing the CWE score, attack methods used by hackers, affected versions, resolution steps, and patch recommendations in a structured table format.

🔒 Is your Splunk instance exposed? Don’t wait for an active breach notification. Our team can assess your Splunk deployment, verify patch status, perform forensic triage, and harden your configuration against follow-on attacks. Contact us today.