What happened
CVE-2026-20253 covers a missing-authentication vulnerability in the PostgreSQL sidecar service endpoint in Splunk Enterprise. NVD rates the vulnerability CVSS v3.1 9.8 (Critical). The CWE classification is CWE-306 (Missing Authentication for Critical Function). The vulnerable versions are Splunk Enterprise 10.2 versions below 10.2.4 and 10.0 versions below 10.0.7. Splunk Enterprise 9.4 and earlier are not affected. CISA added the CVE to the Known Exploited Vulnerabilities catalog on 18 June 2026 with a remediation due date of 21 June 2026, a 3-day window, which is the shortest CISA issues and signals active in-the-wild exploitation of an unauthenticated network-reachable attack surface.
Splunk's advisory confirms that the PostgreSQL sidecar service endpoint lacks authentication controls, which allows any user able to reach the service over the network to invoke file operations without credentials. The vendor-documented impact is the ability to create or truncate arbitrary files on the host running the Splunk instance. The advisory notes that organizations unable to upgrade immediately can mitigate by disabling the PostgreSQL sidecar service. The 3-day KEV window combined with the trivial preconditions (unauthenticated, network-reachable) makes this the kind of vulnerability that gets weaponized within hours of public disclosure and rolled into commodity scanning and exploitation tooling within days.
How it works
The vulnerable endpoint is a service-sidecar pattern: Splunk Enterprise 10.x ships a PostgreSQL sidecar that exposes a service interface used by Splunk internal components to manage configuration, search artifacts, and certain administrative state. The endpoint, in the affected versions, does not enforce an authentication challenge before accepting commands, so the only barrier to using it is network reachability. A network-reachable attacker who can send a request to the endpoint can invoke the file operations the sidecar exposes, which include creating and truncating files on the underlying host.
The interesting operational detail is the sidecar pattern itself. Sidecars are an increasingly common deployment shape for stateful components: the primary application runs alongside a tightly-coupled service (database, cache, message queue) that handles part of the application logic. The pattern is convenient for the developer but creates a new attack surface that is not always subject to the same authentication posture as the primary application. In this case, the sidecar's endpoint was reachable as part of Splunk's network footprint and accepted commands without an authentication challenge, which turns the convenience of the sidecar into an unauthenticated file-system primitive.
Truncating an arbitrary file is a higher-impact primitive than it first sounds. A truncated Splunk configuration file, log file, or binary can render the instance inoperable (denial of service), or, depending on the path truncated, can break Splunk's authentication or authorization checks in ways that the attacker controls. Combined with the ability to create arbitrary files, an attacker can stage payloads in known locations, drop webshells in writable paths, or write to scheduled-task or init-script locations that run as a privileged user on Splunk startup. The Splunk service runs with elevated privileges on most operating systems, which raises the ceiling of what an arbitrary-file primitive can achieve.
Blast radius
The blast radius is any internet-facing or untrusted-network-reachable Splunk Enterprise 10.0 or 10.2 instance that has not been upgraded to the fixed version. Splunk is widely deployed in operational technology, security operations centers, financial services, healthcare, and large enterprise IT. Many Splunk deployments are deliberately reachable from corporate subnets, and many are reachable from the internet for legitimate reasons (cloud-hosted Splunk Cloud, customer-facing Splunk dashboards, federated search from partner networks). The unauthenticated nature of the vulnerability means the threat model is external attacker, not insider.
Once an attacker has arbitrary-file creation or truncation on a Splunk host, the operational impact extends beyond the Splunk instance itself. Splunk forwarders, deployment servers, and search head clusters are integrated with the broader IT estate: a Splunk host often has access to log data for the entire environment, including authentication events, network telemetry, and endpoint telemetry. A compromised Splunk host is a compromised SOC, in the same way that a compromised SIEM is a compromised SOC: the attacker can read the alerts that would have caught them, modify detection rules to suppress their activity, and pivot from the Splunk host into the rest of the environment through the same authentication channels Splunk uses to gather data.
Defender actions
Defender actions for CVE-2026-20253 are time-bounded and have a hard deadline. CISA's due date is 21 June 2026. Steps, in order: identify all Splunk Enterprise 10.0 and 10.2 instances in the environment, including instances that are federated, instances that are part of a search head cluster, and instances that are reachable from the internet. For each instance, check whether the instance is at a fixed version (10.0.7+ or 10.2.4+). If yes, verify the fix is in place and proceed to the post-patch audit. If not, the immediate mitigation is to disable the PostgreSQL sidecar service per Splunk's advisory; this stops the vulnerable attack surface while preserving Splunk's other functionality until the patch can be applied.
Patch to 10.0.7 or 10.2.4 (whichever applies to your version line) within the 3-day window. Splunk Enterprise 9.4 and earlier are not affected by this vulnerability, but they should still be on a current maintenance track for other reasons. After patching, audit the instance for indicators of pre-patch compromise: unusual file-creation activity in the Splunk filesystem, unexpected processes running as the Splunk service user, modified or new files in Splunk's bin, etc, or default directories, unexpected outbound connections from the Splunk host, and modifications to Splunk's authentication configuration. The instances that were externally reachable in the days before the patch should be treated as compromised and the broader IT estate should be audited through the Splunk instance's access patterns, on the assumption that anything the Splunk host could see, the attacker could see.
Lessons
The wider lesson is that sidecar services are an under-instrumented attack surface. The primary application gets the security review, the patch window, the monitoring coverage; the sidecar often ships with the same permissions and a different (or absent) authentication posture. The pattern is now common enough that it deserves a specific detection engineering effort: inventory every sidecar in the environment, verify that each sidecar enforces authentication, and audit the network reachability of each sidecar endpoint. The Splunk CVE is the latest reminder that the sidecar pattern has a security tail that is not always visible from the primary application's threat model.
The other lesson is the recurring pattern of pre-authentication criticals in widely-deployed enterprise software. CISA's 3-day KEV window is reserved for vulnerabilities that are being actively exploited and that have the operational preconditions for broad scanning (network-reachable, unauthenticated, low complexity). The list of 3-day-window CVEs over the last several years is dominated by exactly this pattern: edge appliances, management consoles, and now management sidecars. The defender response is the same in each case: a short patch window driven by the KEV due date, a fallback mitigation per the vendor advisory, and the operational discipline of treating an exposed instance as compromised until you can demonstrate otherwise. None of those are easy to retrofit at scale, which is the underlying operational burden of running enterprise software in 2026.