6 min read<\/p>\n
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.<\/strong><\/p>\n Key Takeaways<\/p>\n Related:<\/span>Patch Prioritisation: Why CVSS Alone Slows Down Your SOC<\/a> \/<\/span> Detection Engineering Without Vendor Lock-in<\/a><\/p>\n What is CVE-2026-20253?<\/strong> A critical vulnerability in Splunk Enterprise\u2019s 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n The escalation unfolded within days. Splunk\u2019s 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n If an immediate update isn\u2019t 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.<\/p>\n 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.<\/p>\n A SIEM\u2019s logs underpin every detection rule. It aggregates the entire network\u2019s logs in one place. If this platform fails or is tampered with, the SOC loses its most critical line of sight.<\/p>\n 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.<\/p>\n 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.<\/p>\n The flaw in Splunk Enterprise\u2019s 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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\u2019s advisory lists concrete detection rules based on confirmed attack patterns; additionally, inspect the logs for unexpected file operations.<\/p>\n 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.<\/p>\n\n
How the flaw enables attacks<\/h2>\n
From Proof-of-Concept to Active Exploitation<\/h2>\n
How Many Systems Are Still Exposed<\/h2>\n
Patch, Shut Down, or Isolate<\/h2>\n
\n
Why SIEM is a particularly sensitive target<\/h2>\n
Frequently Asked Questions<\/h2>\n
What exactly does CVE-2026-20253 allow?<\/h3>\n
Are DACH companies affected even though the CISA deadline applies only to US agencies?<\/h3>\n
What if immediate patching isn\u2019t possible?<\/h3>\n
How can I tell if my Splunk instance is exposed?<\/h3>\n
Why is a flaw in the SIEM especially critical?<\/h3>\n
Editor\u2019s Reading Picks<\/h3>\n