If you run Splunk Enterprise on-premises, stop what you’re doing and check your version. A critical flaw — CVE-2026-20253, carrying a CVSS score of 9.8 — is being actively exploited in the wild, and CISA has already added it to its Known Exploited Vulnerabilities catalog. What makes this one genuinely dangerous is that it needs no credentials at all. Any attacker who can reach your Splunk instance over the network can use it. For most Indian enterprises I work with, Splunk is the SIEM sitting at the very centre of their security operations — which means a compromise here isn’t a side issue, it’s a compromise of the thing that’s supposed to catch everything else.

Here’s what I’m telling every client running self-hosted Splunk this week.

Key takeaways

  • What: CVE-2026-20253, an unauthenticated remote code execution flaw in Splunk Enterprise (CVSS 9.8).
  • How: A PostgreSQL “sidecar” service endpoint ships without authentication, letting any network-reachable attacker create or truncate files — and from there, run code as the Splunk user.
  • Affected: Splunk Enterprise 10.2.0–10.2.3 and 10.0.0–10.0.6 (self-hosted). Splunk Cloud has not been flagged.
  • Status: Added to the CISA KEV catalog on 18 June 2026; public proof-of-concept exploit released by WatchTowr on 12 June; in-the-wild exploitation confirmed.
  • Do now: Upgrade to the fixed release in Splunk’s advisory, and — critically — make sure the PostgreSQL sidecar port is not exposed to any untrusted network.

Why this one keeps me up at night

Most vulnerabilities I triage need something from the attacker — a valid login, a phishing click, a foothold elsewhere first. CVE-2026-20253 needs none of that. The only precondition is network reachability. If your Splunk management or sidecar port is exposed to the internet, or even to a flat internal network that an attacker has already touched, this is a single-step path to code execution.

And remember what Splunk is. It’s your SIEM. It ingests logs from your firewalls, your endpoints, your domain controllers, your cloud accounts. An attacker who lands code execution on Splunk doesn’t just own a server — they own your visibility. They can read every log you collect, learn exactly what your detections look for, and quietly disable or blind the alerts that would otherwise flag their next move. This is the same pattern I wrote about with CitrixBleed 3 and FortiBleed — internet-facing infrastructure software becoming the front door.

The technical breakdown

The root cause is depressingly simple. Splunk Enterprise ships a PostgreSQL sidecar service to support certain features. That service exposes an endpoint that lacks authentication controls — so any user who can reach it over the network can invoke file operations without supplying credentials. An attacker uses that to create or truncate arbitrary files on the host. Once you can write files to a path the Splunk process reads or executes, turning that into remote code execution as the Splunk service account is a well-trodden path.

The timeline matters here, because it tells you how little runway defenders had:

  • 12 June 2026 — WatchTowr publishes a working proof-of-concept demonstrating RCE.
  • By mid-June — limited in-the-wild exploitation observed.
  • 18 June 2026 — CISA adds CVE-2026-20253 to the KEV catalog and sets a remediation deadline under Binding Operational Directive 26-04.

When a public PoC and active exploitation arrive within days of each other, the patch-or-mitigate window is measured in hours, not weeks.

What you should do — my checklist

This is the exact order I’d work through it with a client:

  1. Confirm your exposure. Identify every self-hosted Splunk Enterprise instance and its version. If you’re on 10.2.0–10.2.3 or 10.0.0–10.0.6, you are in scope. Don’t trust the asset inventory blindly — scan for it.
  2. Patch. Upgrade to the fixed maintenance release named in Splunk’s official security advisory. This is the only real fix.
  3. If you can’t patch this hour, mitigate. Restrict network access to the Splunk management and PostgreSQL sidecar ports so they’re reachable only from a tightly controlled admin segment — never the internet, never a flat user VLAN. Network segmentation buys you time the patch cycle won’t.
  4. Hunt for compromise. A patch closes the door; it doesn’t tell you whether someone already walked through. Review the Splunk host for unexpected files, new processes running as the Splunk user, outbound connections, and modified configurations. Check access to the sidecar endpoint in your logs.
  5. Rotate and review. If you find any sign of access, treat the SIEM as compromised: rotate credentials and tokens Splunk holds, and assume the attacker saw your detection logic.

If exploitation is confirmed, your clock is now also a compliance clock. Under CERT-In’s directions, certain cyber incidents must be reported within six hours of detection — and if personal data is implicated, your obligations under the DPDP Act follow close behind. The response and the reporting need to run in parallel, not one after the other. This is exactly the muscle I drilled in my piece on the first 60 minutes of a ransomware incident.

The bigger lesson: your security tools are attack surface too

I keep coming back to this with clients, because it’s uncomfortable but true: the appliances and platforms you buy to be secure — VPNs, firewalls, SIEMs — are themselves software, and they sit in privileged positions on your network. When they fail, they fail catastrophically, because they’re trusted by everything around them. The defensive answer isn’t to stop using them; it’s to treat them with the same zero-trust discipline as everything else: minimal network exposure, strict segmentation, rapid patching, and continuous monitoring of the tools themselves.

Frequently asked questions

Is Splunk Cloud affected?

The advisories single out self-hosted Splunk Enterprise on the listed versions. Splunk Cloud has not been flagged in the same way, but if you run Splunk Cloud you should still confirm your status directly with Splunk’s advisory rather than assume.

We’re behind a firewall — are we safe?

Only if that firewall genuinely isolates the Splunk management and sidecar ports from any network an attacker could reach, including your internal user network. “Behind the firewall” is not the same as “unreachable.” Flat internal networks are exactly how an initial foothold turns into a SIEM compromise.

If we patch, are we done?

Patching stops future exploitation, but it does not undo a compromise that already happened. Given that a public PoC and active exploitation pre-date many organisations’ patching, you should hunt for indicators of prior access before you call it closed.

How fast do we really need to move?

Treat it as same-day. CISA’s KEV listing exists precisely because this is being exploited now, and a public exploit makes mass scanning trivial. Every hour an unpatched, network-reachable instance stays up is meaningful risk. In practice, I tell clients to mitigate by network restriction within the hour even if a full patch and reboot has to wait for a maintenance window later the same day — closing the network path is faster than closing the code path, and it stops the bleeding immediately.

Need a hand?

If you’re not certain whether your Splunk deployment — or any of your internet-facing infrastructure — is exposed, that uncertainty is itself the problem worth fixing. I help Indian enterprises find these gaps before attackers do, and build the segmentation and monitoring that contains them when something like CVE-2026-20253 inevitably comes along. Get in touch for a focused security assessment and let’s make sure your security stack isn’t your softest target.