The Splunk Vulnerability That Deletes Log Files Without Authentication

6 min read

A critical gap in Splunk Enterprise allows attackers to create and delete files on the server without authentication. Since 18 June, the US authority CISA has listed it as actively exploited. Over 1,400 instances are exposed online worldwide, 223 of them in Europe.

Key Takeaways

CVSS 9.8, no login required. Vulnerability CVE-2026-20253 resides in Splunk Enterprise’s PostgreSQL sidecar and enables file creation and deletion without authentication.
Attacks are already underway. After public exploit code was released on 12 June, CISA added the flaw to its list of actively exploited vulnerabilities on 18 June, with a patch deadline of 21 June for US federal agencies.
Workaround sacrifices features. Organisations unable to patch immediately can disable the PostgreSQL sidecar, losing Edge Processor, OpAmp and SPL2 data pipelines in the process.

How the flaw enables attacks

What is CVE-2026-20253? A critical vulnerability in Splunk Enterprise’s PostgreSQL sidecar that bypasses authentication, letting attackers create and delete files on the server without logging in. The CVSS score is 9.8 out of 10.

Splunk Enterprise has run a PostgreSQL sidecar for several releases. This auxiliary service runs alongside the main Splunk process and feeds a relational database to Edge Processor, the OpAmp telemetry protocol and the SPL2 data pipelines. The flaw sits right there.

CVE-2026-20253 is a missing authentication check. An attacker needs no login, no account, no valid session. They can leverage the exposed service to create and delete files on the system.

While less dramatic than classic remote code execution, the damage potential remains high. Unauthenticated file creation and deletion can cripple components or erase logs. Depending on the environment, such access can be escalated into broader attacks. The CVSS score of 9.8 classifies the flaw as critical, largely because it is trivial to exploit without authentication.

From Proof-of-Concept to Active Exploitation

The escalation unfolded within days. Splunk’s Product Security Incident Response Team confirmed the first attacks in early June. The turning point came when a publicly available Proof-of-Concept was released.

From Exploit to Agency Deadline

Early June

Splunk PSIRT confirms first attacks targeting the vulnerability.

12 June

WatchTowr Labs publishes a working Proof-of-Concept.

18 June

CISA adds CVE-2026-20253 to the Known Exploited Vulnerabilities catalog.

21 June

Deadline for U.S. federal agencies to remediate the flaw.

Six days from public exploit to KEV listing is a razor-thin window. Once a Proof-of-Concept circulates, the barrier to mass-scanning exposed systems plummets. Waiting for the next regular maintenance cycle is simply too slow.

How Many Systems Are Still Exposed

Splunk collects logs across the entire network and is therefore often widely connected. Some instances sit directly on the internet-often out of convenience at distributed sites.

223

internet-accessible Splunk instances in Europe, out of more than 1,400 worldwide.

Source: public scan data for the vulnerability, June 2026

Every exposed instance is a direct target. Even internally reachable servers remain vulnerable once an attacker gains a foothold-say, after a phishing hit. Internet exposure must be closed first, internal instances immediately after.

Patch, Shut Down, or Isolate

The priority is clear. Splunk provides a patch. The Splunk Security Advisory for CVE-2026-20253 lists affected builds and the version that closes the gap. Splunk Enterprise users should compare their build and apply the update-this is the only measure that truly closes the hole.

If an immediate update isn’t possible, the stopgap is to disable the PostgreSQL sidecar. That halts the vulnerable service, but at a cost: Edge Processor, OpAmp, and SPL2 data pipelines go offline. For many environments, the loss of function is noticeable and only suitable as a stopgap.

Regardless of patch status, internet exposure must be reviewed. A SIEM rarely has a valid reason to sit exposed on the internet. Restricting access to internal networks and a VPN shrinks the attack surface immediately.

Immediately: Check build, apply patch.
If no patch is possible: Disable PostgreSQL sidecar, plan for downtime.
In any case: Review internet exposure, limit access to VPN and internal networks.
Afterwards: Scan logs for unexpected file operations and deleted entries.

Why SIEM is a particularly sensitive target

A SIEM’s logs underpin every detection rule. It aggregates the entire network’s logs in one place. If this platform fails or is tampered with, the SOC loses its most critical line of sight.

The ability to delete files makes the situation worse. An attacker who removes logs erases their tracks precisely where they would otherwise be spotted. A gap in the detection system is therefore more dangerous than the same gap on a peripheral system. It strikes the very instance that is supposed to report the attack.

In practice, this means: the vulnerability is no ordinary patch among many. It affects the component on which the credibility of every other alert depends.

Frequently Asked Questions

What exactly does CVE-2026-20253 allow?

The flaw in Splunk Enterprise’s PostgreSQL sidecar bypasses authentication. An attacker can create and delete files on the system without valid credentials. Depending on the environment, this can disable components or remove logs.

Are DACH companies affected even though the CISA deadline applies only to US agencies?

Yes. The CISA deadline obliges only US federal agencies; the technical risk is identical everywhere. Splunk is deployed in many DACH SOCs, and the 223 exposed instances in Europe show that systems are open here as well. Anyone running Splunk should treat 21 June as their own deadline.

What if immediate patching isn’t possible?

Splunk recommends temporarily disabling the PostgreSQL sidecar service. This stops the vulnerable service, but Edge Processor, OpAmp and the SPL2 data pipelines also go offline. Use this measure only as a stopgap until the patch can be applied.

How can I tell if my Splunk instance is exposed?

The quickest indicator is external reachability: check whether the PostgreSQL sidecar service responds from the internet or untrusted segments. Since a public exploit has been circulating since 12 June, any exposed instance is acutely endangered. Splunk’s advisory lists concrete detection rules based on confirmed attack patterns; additionally, inspect the logs for unexpected file operations.

Why is a flaw in the SIEM especially critical?

The SIEM supplies the logs for every detection. If it is manipulated, the security team loses visibility into its own network. Because the flaw also allows file deletion, an attacker can erase their tracks exactly where they would otherwise be noticed.