SURIQ
The platform you bought to watch for intrusions can now be the intrusion. CVE-2026-20253 is an unauthenticated remote code execution flaw in Splunk Enterprise, rated 9.8, and CISA added it to its Known Exploited Vulnerabilities catalog on June 18 after confirming attacks in the wild. The patch landed on June 10. Exploitation followed within days. If you run Splunk Enterprise 10.x, this is today's work.
The detail most coverage buries is where the bug lives. It is not in search, in the REST API you already secured, or in the dashboards your analysts open. It is in a PostgreSQL service that Splunk 10 bundles to back its KVStore, running quietly beside the main process. Most teams never configured it, and many did not know it was listening.
What CVE-2026-20253 actually is
Splunk 10 moved its KVStore onto a bundled PostgreSQL sidecar process. That sidecar exposes a set of backup and restore endpoints under paths like /v1/postgres/recovery/backup on an internal port, 5435. Those endpoints perform no application-level authentication. Empty credentials are accepted.
Localhost-only endpoints would be a smaller problem. In practice they are not localhost-only. SplunkWeb forwards requests to the sidecar through its __raw proxy. A front-end URL that tunnels into the backup endpoint reaches the database service from the same web interface an attacker can already touch. That is the server-side request forgery that turns an internal port into a remote one.
From there the chain is short. The backupFile parameter accepts directory traversal, so files can be written outside the intended backup directory. PostgreSQL's own connection-string parsing lets an attacker supply hostaddr= and override the hardcoded -h localhost, pointing Splunk at an attacker-run database. A malicious restore then writes attacker-controlled content to an arbitrary path, and overwriting a Python file that Splunk executes (researchers used ssg_enable_modular_input.py) yields code execution as the Splunk service account. No password at any step.
Your deployment shape decides your risk, not just your version
Here is the part a version check misses. The sidecar is not present and enabled everywhere. Resecurity's breakdown maps the risk to how Splunk was installed: a manual on-prem install may not have the service at all, an on-prem install that does have it ships with it disabled by default, and AWS deployments ship with it enabled by default.
That inverts the usual intuition. The hand-built box an engineer fussed over is often the safe one. The clean, click-to-deploy AWS instance, the one nobody had to think about, is the exposed one. If your answer to "are we affected" is only a version number, you are answering the wrong question. The real question is whether that PostgreSQL service is running and reachable, and on AWS the default answer is yes.
Why a SIEM RCE is its own category of bad
Pre-auth RCE is severe on any host. On a SIEM it is worse, and the reason is rarely stated. Your log platform is the system of record for everything else. An attacker who runs code there does not just gain a foothold. They gain the ability to read, alter, or delete the telemetry your team would use to notice them. The break-in and the cover-up use the same access.
This is the pattern we keep writing about: the security appliance that becomes the entry point, the patch service that becomes the breach. A tool earns deep trust and broad reach inside the network, and that trust is what makes it worth attacking. Treat the platform you trust to watch everything as one of the most sensitive boxes you own, because an attacker already does.
What to do this week
Patch first. Splunk fixed Splunk Enterprise in 10.0.7 and 10.2.4; Splunk Cloud instances are updated by Splunk. CISA's three-day deadline for federal agencies is unusually short, and that is a signal in itself: the agency expects this to move fast, so pre-stage the change window rather than routing it through a normal monthly cycle.
If you cannot patch instantly, confirm whether the PostgreSQL sidecar is reachable and restrict it. The same default-configuration question that decided exploitability in other recent bugs applies here: an endpoint that should never face the network often does anyway.
For detection, the exploit leaves a recognizable shape. On the internal Postgres endpoints, alert on traversal markers like ../ and on any request that smuggles database connection arguments: hostaddr=, dbname=, passfile=. Flag pg_dump or pg_restore running when no backup is scheduled, and database dump files appearing in unusual locations. Those signals belong in your alerting before you assume the patch closed every exposed instance.