CVE-2026-20253: How to Stop the Unauthenticated Splunk Enterprise RCE Before the Patch Lands

Thank you!

You're subscribed!

Oops! Something went wrong while submitting the form.

‍
An unauthenticated remote code execution flaw in Splunk Enterprise (CVE-2026-20253, CVSS 9.8) lets attackers create or overwrite files on the Splunk host through an exposed PostgreSQL sidecar endpoint, and a public exploit chain turns that into full RCE as the Splunk service account. Miggo keeps the watcher seeing straight, blocking the exploit at the edge with a validated Miggo WAF Copilot rule and stopping the file write and code execution behavior at the call stack level with its runtime sensor. Watch in 90 seconds how our customers are protected even before the Splunk patch is rolled out.

Splunk Enterprise is the watcher, the platform tens of thousands of security teams trust to catch attackers, and CVE-2026-20253 shows how easily an unauthenticated attacker can blind it. Ironically, it’s the system built to catch intruders that can now be hijacked by them: this unauthenticated flaw in Splunk Enterprise lets any attacker on the network execute code as the Splunk service account, no login required.

Compromising a Splunk instance does more than grant entry to a network: it gives attackers a foothold inside the platform used to see and obfuscate the very incident they are causing. Any attacker who can reach the Splunk Web interface over the network can invoke privileged file operations without credentials (because Splunk Web fronts that endpoint as a reverse proxy and never enforces authentication on it).

In this post, we break down how the exploit chain works, what a successful attack gives an attacker access to, and the two layers of runtime defense Miggo has in place to stop it before Splunk's patch lands.

Background

CVE-2026-20253 is a critical, unauthenticated vulnerability in Splunk Enterprise, disclosed by Splunk on June 10, 2026 (advisory SVD-2026-0603). It carries a CVSS score of 9.8 and stems from a missing authentication control (CWE-306) on a PostgreSQL sidecar service endpoint that handles database backup and recovery.

Video: Walkthrough of Splunk Enterprise 10.0.6 and the pre-auth PostgreSQL recovery API.

On June 18, 2026, Splunk confirmed exploitation in the wild and CISA added the flaw to its Known Exploited Vulnerabilities (KEV) catalog, the first Splunk vulnerability ever to appear on that list, with a federal remediation deadline of June 21, 2026. Public proof-of-concept code from watchTowr Labs was published on June 12, and confirmed abuse followed within days.

CVE	CVE-2026-20253 (Splunk advisory SVD-2026-0603)
Severity	CVSS 9.8 – Critical
Weakness	CWE-306, missing authentication on a privileged endpoint
Authentication	None required (pre-auth)
Disclosed	June 10, 2026
KEV / In the Wild	Added to CISA KEV on June 18, 2026; active exploitation confirmed
Fixed In	Splunk Enterprise 10.0.7, 10.2.4, and later

CVE:
CVE-2026-20253 (Splunk advisory SVD-2026-0603)

Severity:
CVSS 9.8 – Critical

Weakness:
CWE-306, missing authentication on a privileged endpoint

Authentication:
None required (pre-auth)

Disclosed:
June 10, 2026

KEV / In the Wild:
Added to CISA KEV on June 18, 2026; active exploitation confirmed

Fixed In:
Splunk Enterprise 10.0.7, 10.2.4, and later

Note: on AWS deployments the PostgreSQL sidecar service is enabled by default. Splunk Cloud is not affected because it does not use the Postgres sidecar.

The Exploit Process

Splunk Enterprise ships a PostgreSQL sidecar service that performs backup and recovery. Its recovery endpoints are reachable through Splunk Web (default TCP port 8000), which proxies requests to the internal sidecar without applying authentication.

Unauthenticated reach. The attacker sends a crafted HTTP POST to Splunk Web, which forwards it to the internal recovery endpoint at /en-US/splunkd/__raw/v1/postgres/recovery/backup. No credentials are required.
Arbitrary file primitive. The backup endpoint passes the request's backupFile value to pg_dump as the output path with no validation, so an unauthenticated attacker can write a file to any location on the host, using an absolute path or a ../ traversal.
Escalation to RCE. Public research chained the file primitive through PostgreSQL behavior: forcing connections to an attacker-controlled database server, abusing .pgpass and connection strings, pg_dump and pg_restore, and lo_export to write a controlled file. Overwriting a script that Splunk later runs yields code execution.
Miggo security researchers have found an alternative RCE chain using the COPY TO PROGRAM postgres feature, and more probably exist, as escalation from file write to RCE is definitely not unheard of.

Code execution as Splunk. The injected code runs with the privileges of the Splunk service account, enabling log tampering, credential theft, and lateral movement.

This is the core of CVE-2026-20253: a privileged internal recovery service exposed across a trust boundary with no application-level authentication. What the advisory frames as file operations becomes a pre-authentication path to full host compromise.

Version exposure

Status	Splunk Enterprise Versions
Affected	10.0.0–10.0.6 and 10.2.0–10.2.3
Fixed	10.0.7, 10.2.4, and later releases
Not affected	10.4.0 and later; all Splunk Cloud Platform versions; 9.4.x and earlier

Status:
Affected

Splunk Enterprise Versions:
10.0.0–10.0.6 and 10.2.0–10.2.3

Status:
Fixed

Splunk Enterprise Versions:
10.0.7, 10.2.4, and later releases

Status:
Not affected

Splunk Enterprise Versions:
10.4.0 and later; all Splunk Cloud Platform versions; 9.4.x and earlier

Note: on AWS deployments the PostgreSQL sidecar service is enabled by default. Splunk Cloud is not affected because it does not use the Postgres sidecar.

The Blast Radius

A successful exploit gives attackers:

Arbitrary code execution on the Splunk host as the Splunk service account
The ability to create, truncate, or overwrite files, including Splunk's own scripts and configuration
Tampering with indexed data, dashboards, saved searches, and alerts to hide activity or blind detection
Access to sensitive logs, tokens, and credentials stored in apps and configurations
Outbound connections to attacker-controlled PostgreSQL servers, and a pivot point for lateral movement

When the platform under attack is the one your SOC uses to detect attacks, the blast radius extends to your ability to respond.

The Miggo Edge: Two Layers of Runtime Defense

Miggo is built for this exact threat model: vulnerabilities exploited at runtime, often before a patch is available or deployed. For CVE-2026-20253, Miggo provides protection at two layers (see the video above for the demo).

Immediate mitigation at the edge: a validated WAF Copilot rule

WAF Copilot generates and validates a targeted virtual-patch rule for CVE-2026-20253, then deploys it to your WAF (for example, AWS WAF, Cloudflare, Akamai, or F5). The rule inspects requests bound for the Splunk Web reverse-proxy path and blocks those that match the exploit signature: requests to the Postgres recovery endpoints carrying attacker-controlled PostgreSQL connection parameters such as postgres://, host=, hostaddr=, service=, passfile=, options= . Because the rule is validated against both the live exploit and legitimate traffic before it ships, it stops the attack without breaking normal Splunk operation.

*WAF Copilot in AWS WAF: the Splunk PostgreSQL sidecar pre-auth rule deployed on the CloudFront Web ACL, running in BLOCK mode.*

Real time detection in the workload: catching behavior, not signatures

Beyond the edge, Miggo's runtime sensor watches application behavior at the syscall level, so it catches exploitation even if a request slips past perimeter controls.

Behavioral profiling. Miggo learns which files the Splunk process normally writes and which subprocesses it normally spawns. An unexpected write into Splunk's executable paths, or an unexpected child process, is flagged as drift from the baseline, with no signature or prior CVE knowledge required.
Network-to-payload correlation. Miggo links the inbound request hitting the recovery endpoint to the file operation and process activity it triggers on the host, and to outbound connections to unrecognized PostgreSQL servers. That end-to-end link is something neither network-only nor endpoint-only tools can reconstruct.
Runtime blocking. Miggo's enforcement layer intercepts the malicious file write or the injected subprocess before it runs, neutralizing the RCE without disrupting the Splunk process.

The result: Miggo customers are protected even if they have not yet patched, and even if an attacker reaches the vulnerable endpoint.

What To Do Now

Patch first. Upgrade Splunk Enterprise to 10.0.7, 10.2.4, or 10.4.0 and later.

If you cannot patch immediately:

Use your WAF. Miggo provides customers with tailor-made rules for this vulnerability.
Disable the PostgreSQL sidecar service via $SPLUNK_HOME/etc/system/local/server.conf and restart Splunk. Caution: this breaks Edge Processor, OpAmp, and SPL2 data pipelines, so confirm you do not depend on them first.
Remove Splunk Web (port 8000) from direct internet exposure and place it behind identity-based, zero-trust access.
Restrict the management interface and sidecar to trusted network segments only.

Hunt for indicators of compromise:

Requests with path traversal (../) or PostgreSQL connection string parameters (postgres://, host=, hostaddr=, service=, passfile=, options= ) to the recovery endpoint.
Outbound connections from Splunk to unknown PostgreSQL servers.
Unexpected files in directories such as /tmp/ or /opt/splunk/var/run/supervisor/pkg-run/, and the public-PoC marker file /opt/splunk/share/splunk/search_mrsparkle/exposed/watchTowr.txt.
Modified or overwritten Splunk Python scripts, notably in the splunk_secure_gateway app.

With Miggo deployed:

Ensure your Splunk workloads are covered by Miggo's runtime sensor.
Deploy the WAF Copilot rule for CVE-2026-20253 to your WAF.
Review Pulse and runtime ADR alerts for the detection signals above.

Mapped MITRE ATT&CK techniques: T1190 (Exploit Public-Facing Application), T1059 (Command and Scripting Interpreter), T1569.002 (System Services: Service Execution), T1105 (Ingress Tool Transfer).

The Takeaway

CVE-2026-20253 is a sharp reminder that the security stack is part of the attack surface. A missing authentication check on an internal recovery service turned the SIEM itself into an entry point, and a published exploit chain collapsed the gap between arbitrary file write and full RCE within days. Authentication controls and patch cycles alone are not enough when exploitation moves this fast. By blocking known exploit patterns at the edge with WAF Copilot and enforcing runtime behavior with its runtime sensor, Miggo keeps customers protected in the window between disclosure and patch.

Check your Splunk exposure

Running Splunk Enterprise and want to verify your exposure, or see how Miggo protects your runtime between patch cycles? Request a demo.

<script src="https://cdn.jsdelivr.net/npm/gsap@3.12.5/dist/gsap.min.js"></script>
<script src="https://cdn.jsdelivr.net/npm/gsap@3.12.5/dist/Flip.min.js"></script>

<script>
  document.addEventListener("DOMContentLoaded", (event) => {
    gsap.registerPlugin(Flip);
    const state = Flip.getState("");
    const element = document.querySelector("");
    element.classList.toggle("");
    Flip.from(state, {
      duration: 0,
      ease: "none",
      absolute: true,
    });
  });
</script>

<script src="https://cdn.jsdelivr.net/npm/gsap@3.12.5/dist/gsap.min.js"></script>
<script src="https://cdn.jsdelivr.net/npm/gsap@3.12.5/dist/Flip.min.js"></script>

<script>
  document.addEventListener("DOMContentLoaded", (event) => {
    gsap.registerPlugin(Flip);
    const state = Flip.getState("");
    const element = document.querySelector("");
    element.classList.toggle("");
    Flip.from(state, {
      duration: 0,
      ease: "none",
      absolute: true,
    });
  });
</script>