A critical, unauthenticated vulnerability in Splunk Enterprise can let a remote attacker write files and ultimately run their own code on the server, and cloud deployments are exposed straight out of the box. Splunk published an advisory for the flaw, tracked as CVE-2026-20253 and rated 9.8 out of 10, on June 10, 2026. Researchers at watchTowr, led by Piotr Bazydlo (@chudyPB), have since reverse engineered it and published a full exploit chain.
The bug lives in a component called the PostgreSQL Sidecar Service, a helper database that Splunk version 10 and later runs alongside the main product. Crucially, whether you are exposed depends on how Splunk is installed. On manually installed Windows servers the sidecar is either absent or switched off by default, but on Splunk Enterprise running in AWS it is installed and enabled automatically. In watchTowr's words, "Splunk Enterprise on AWS is vulnerable out of the box."
How the attack works
The sidecar exposes a backup and restore API that, by design, performs no real authentication. This is the same unauthenticated-backup-endpoint pattern recently seen in Nginx UI, where an exposed backup API leaked full server secrets. It accepts any username with an empty password and forwards whatever it is handed to the underlying PostgreSQL tools. An attacker can reach it by proxying requests through Splunk's main web interface, which listens on every network interface on port 8000.
From there the watchTowr team chained several weaknesses together. The backup endpoint passes an attacker-controlled file path to PostgreSQL's pg_dump tool, giving a path traversal primitive that can create or empty any file on disk. They then smuggled a PostgreSQL connection string into the "database" field, which overrode the hardcoded "localhost" target and forced Splunk to connect to a database the attacker controlled. After finding a ".pgpass" credentials file on disk that handed over the local "postgres_admin" account, they used the restore endpoint to replay attacker-supplied SQL into the local database. A small PostgreSQL function using lo_export turned that into a fully controlled file write as the splunk user.
The final step was straightforward. They overwrote a Python script that Splunk runs itself (ssg_enable_modular_input.py) with a malicious payload, achieving remote code execution. In short, an internet-reachable Splunk Enterprise on AWS can be taken over by an attacker who never needs a single valid credential.
What's affected
CVE-2026-20253 affects Splunk Enterprise version 10 and above where the PostgreSQL Sidecar Service is installed and enabled, which is the default on AWS. On-premise installations are not exposed unless an administrator has turned the sidecar on, so the immediate risk concentrates on cloud-hosted deployments.
What you should do
Apply the fixed versions listed in Splunk's advisory as a priority, especially for any AWS-hosted Splunk Enterprise instance, and confirm whether the PostgreSQL sidecar is enabled in your environment. Until you can patch, restrict network access to the Splunk web port (8000) and keep management interfaces off untrusted networks. Splunk Enterprise is widely deployed as a logging and SIEM backbone, so a pre-authentication takeover of the platform that collects an organization's security data is a high-value target, and public exploitation details now exist; as with the Ivanti Sentry flaw, in-the-wild attacks tend to follow a public exploit within days. Read watchTowr's original write-up for the full technical chain.
This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.