Splunk Enterprise Will Let an Unauthenticated Stranger Write Files to Your SIEM. It's Being Exploited Days After Disclosure. The Watchtower Has a Hole in the Floor.
- Patrick Duggan
- 12 minutes ago
- 3 min read
Splunk is the tool a lot of security teams stare at all day. It ingests the logs, runs the detections, and is supposed to be the place you find out you were attacked. CVE-2026-20253 turns that around. It is a missing-authentication flaw in Splunk Enterprise that lets an attacker with no credentials at all create or truncate files on the system through a PostgreSQL sidecar service endpoint. CISA added it to the Known Exploited Vulnerabilities catalog, and it is being used in attacks within days of the public disclosure.
What the bug lets someone do
The phrase to sit with is missing authentication for a critical function. It means a function that should have required a login did not check for one. An unauthenticated attacker can reach a PostgreSQL sidecar endpoint and use it to create arbitrary files or truncate existing ones. Creating files where you should not be able to is a classic first move toward code execution, dropping a web shell or a scheduled task. Truncating files is the quieter, nastier half. The tool that holds your logs now has an unauthenticated path to zero out files, and the files a smart attacker truncates first are the ones that would have recorded them being there.
Why the target matters
An unauthenticated file-write in an ordinary web app is a bad day. The same flaw in your SIEM is a bad day that erases its own evidence. Splunk sits at the center of a lot of security programs precisely because it is where the record lives. An attacker who can write and truncate files on that box is standing inside the room where you keep the security camera footage, with the ability to add frames and delete them. Detection assumes the detector is trustworthy. This flaw attacks that assumption directly, which is why exploited-in-days is the part that should move it to the top of your queue.
Do this now
Patch to the fixed Splunk Enterprise version today. This is exploited in the wild, so treat any instance you cannot patch immediately as reachable and assume the PostgreSQL sidecar endpoint is not exposed to anyone who does not need it. Get the management and sidecar interfaces off the open internet and behind an allowlist or VPN. Then do the assume-breach step, because the truncation capability means you cannot fully trust the very logs you would use to check: look for files created or zeroed around the disclosure window, unexpected processes, and gaps in your own Splunk audit trail. On a box with an unauthenticated truncate primitive, a gap in the logs is exactly what a covered trail looks like. Chase it like a lead, because it is one.
We hold our certainty at 95 percent. Splunk and CISA have confirmed the flaw and active exploitation. What no one can hand you is a clean count of who was already inside before the patch, and on a tool whose whole job is to remember, the ability to make it forget is the reason that count will always be lower than the truth.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.