Introduction
Security monitoring platforms sit at the heart of enterprise defence: they aggregate event logs, detect anomalous behaviour, and give SOC teams visibility across the entire attack surface. That is precisely why CVE-2026-20253 — publicly disclosed on 12 June 2026 — demands immediate attention. The vulnerability affects Splunk Enterprise, one of the most widely deployed SIEM platforms in the industry, and allows an unauthenticated attacker to execute arbitrary code on the targeted server. CVSS score: 9.8.
An Internal Component Shipped Without Protection
The exploit chain centres on an ancillary service introduced with Splunk Enterprise version 10: the PostgreSQL Sidecar. This component handles backup and restore operations for the internal database through an HTTP API, exposing endpoints including /v1/postgres/recovery/backup and /v1/postgres/recovery/restore. The flaw is architectural: no identity verification is performed at the application layer. Authentication is delegated entirely to the database layer itself, creating a critical gap between the two tiers.
The service listens on internal ports bound to the local interface, but remains reachable from outside via port 8000 on the Splunk web interface, which acts as a transparent proxy. Any attacker who can reach the administration interface can therefore interact with this service without supplying a single credential.
A Four-Step Exploit Chain — Zero Accounts Required
watchTowr Labs documented the full attack chain. In the first step, the attacker sends a request to the backup endpoint, injecting a PostgreSQL connection parameter pointing to a server they control — the database field accepts full connection strings, including the hostaddr parameter, which overrides the default target address.
From that rogue server, the attacker can then restore a dump containing PL/pgSQL functions designed to write arbitrary files onto the host filesystem. The next step is to retrieve local credentials stored in a .pgpass file — sufficient to authenticate against the local Splunk database. Finally, overwriting a Python script that the platform executes on a regular schedule results in code execution as the splunk user. No prior privilege escalation, no platform account: network access to port 8000 is all it takes.
AWS Deployments Exposed by Default
One factor sets this vulnerability apart from typical CVEs: the PostgreSQL Sidecar service is enabled by default in Splunk Enterprise deployments on AWS, but remains inactive or absent in the majority of on-premises Windows installations. Cloud environments were therefore exposed from the moment of deployment, with no additional action required on the operator's part.
This detail illustrates a risk that is consistently underestimated: the attack surface of a cloud deployment can differ significantly from its on-premises equivalent, even for the same vendor and the same product. Hardening policies designed for physical servers do not automatically translate to cloud environments, and components enabled by default in managed environments warrant a dedicated audit.
What This Means for Security Teams
Splunk released patched versions on 10 June 2026: branches 10.4.0, 10.2.4, 10.0.7, 9.4.12, and 9.3.13 all include the fix. Patching should be treated as a priority for any organisation running Splunk on AWS, where the service was active without teams necessarily being aware of it.
More broadly, this incident is a reminder that security tooling itself must be held to the same standard as any other critical component: maintain an inventory of exposed services, audit internal endpoints, and verify that authentication architecture does not delegate responsibility to unfiltered sub-components. Monitoring the entire IT estate means nothing if the monitoring tool is not itself hardened.