Splunk’s Security Data Could Be Damaged Without a Login
Splunk CVE-2026-20253 allowed an unauthenticated attacker to create or truncate arbitrary files through a PostgreSQL sidecar endpoint, giving an intruder a path to damage the evidence platform itself.
The vulnerability carries a CVSS score of 9.8. It affects Splunk Enterprise 10.0.0 through 10.0.6 and 10.2.0 through 10.2.3. Splunk fixed the issue in 10.0.7 and 10.2.4. Version 10.4.0 is not affected, nor are 9.4 and earlier branches. Splunk Cloud Platform is also outside the advisory.
Splunk initially published the advisory on 10 June 2026 and updated it on 18 June to state that limited exploitation was known. That change turns the issue from a theoretical integrity risk into a reason to examine whether security data was altered before the fix arrived.
The vulnerable component and the affected branches
| Item | Verified detail |
|---|---|
| Vulnerability | CVE-2026-20253, unauthenticated arbitrary file creation or truncation through a PostgreSQL sidecar endpoint |
| Affected 10.0 branch | 10.0.0 through 10.0.6; fixed in 10.0.7 |
| Affected 10.2 branch | 10.2.0 through 10.2.3; fixed in 10.2.4 |
| Unaffected releases | 10.4.0 and Splunk Enterprise 9.4 or earlier |
| Splunk Cloud | Not affected |
| Exploitation status | Splunk says limited exploitation is known |
| Workaround | Disable the PostgreSQL sidecar only after checking dependencies, because Edge Processor, OpAmp and SPL2 pipelines may stop working |
Integrity is the security property that matters here
The vulnerability does not need to provide a conventional interactive shell to become operationally serious. Arbitrary file creation can change application state, plant content or interfere with service behaviour. File truncation can destroy logs, configurations or other data the platform needs to operate and to prove what happened.
That is especially consequential on a SIEM or analytics platform. Security teams depend on Splunk to retain event history, correlate alerts and support incident response. If an attacker can damage files without authenticating, defenders must consider not only whether the platform was breached, but whether its records remain complete and trustworthy.
Splunk says its core search, indexing and dashboard functions are not affected by disabling the sidecar. The caveat is important: organisations using Edge Processor, OpAmp or SPL2-based pipelines can break those features or trigger cascading issues if they apply the workaround blindly.
What defenders should do
- Upgrade to 10.0.7, 10.2.4 or a later unaffected release. Verify the installed version on every self-managed Splunk Enterprise node.
- Map sidecar dependencies before using the workaround. Confirm whether Edge Processor, OpAmp or SPL2 pipelines depend on it.
- Preserve independent telemetry. Retain operating-system, network, endpoint and storage records outside Splunk before restarting or repairing the platform.
- Check file integrity. Review unexpected file creation, zero-length or truncated files, modified configurations and unexplained service failures.
- Investigate the exposure period. Because exploitation is confirmed, examine requests to the sidecar endpoint and correlate them with host-level changes.
- Validate evidence continuity. Compare event volumes and retention gaps against upstream sources to identify missing or altered data.
The BlackTree view
A security platform can be attacked as infrastructure, but it can also be attacked as evidence. The ability to truncate files creates doubt precisely where responders need certainty.
Patch the endpoint, then verify the history. If Splunk was reachable during the vulnerable period, the absence of an alert inside Splunk cannot by itself prove that nobody tried to damage Splunk.
Sources and publication details
- Splunk Security Advisory SVD-2026-0603, published 10 June 2026 and updated 18 June 2026. No publication times were provided.
