How CVE-2026-20253 Turns Splunk’s PostgreSQL Sidecar Into an Open Door

How CVE-2026-20253 Turns Splunk’s PostgreSQL Sidecar Into an Open Door Security teams using Splunk Enterprise for log collection and threat detection need to patch now. Splunk CVE-2026-20253, published in advisory SVD-2026-0603 on June 10, 2026, affects the PostgreSQL sidecar service bundled with Splunk Enterprise. The flaw scores CVSS 9.8 and requires zero authentication. A public proof-of-concept appeared on GitHub on June 13. Here is the technical picture and what you need to do.

The Vulnerable Component: PostgreSQL Sidecar Endpoint Splunk Enterprise ships a PostgreSQL sidecar service alongside its core processes. This service exposes an endpoint for file operations, creating and truncating files on the host filesystem. The endpoint shipped with no authentication controls. That makes it a textbook case of CWE-306: Missing Authentication for Critical Function.

Any attacker who reaches the endpoint over the network can send crafted requests. Those requests create new files or truncate existing ones on the host. No session token, no API key, no certificate required. Just a network packet reaching the right port is enough.

The RCE Chain: From File Write to Code Execution A file write primitive is already a serious finding in most penetration tests. Against Splunk, however, researchers found the chain extends further. PostgreSQL’s built-in lo_export function writes content from a database large object to a specified path on the filesystem. By combining the unauthenticated endpoint with lo_export, an attacker places a malicious script at a path that Splunk services later execute.

The result is remote code execution on the Splunk server without any valid credentials. Orca Security and NetSPI independently documented this chain after Splunk’s disclosure. Horizon3.ai released a Rapid Response test for the flaw on June 15.

Affected Versions Splunk CVE-2026-20253 is present in the following releases:

Splunk Enterprise 10.0.x through 10.0.6 Splunk Enterprise 10.2.x through 10.2.3 Splunk Cloud Platform versions below 10.4.2604.3 and 10.2.2510.14 The June 10 advisory also patched three other flaws from the same batch: CVE-2026-20251 (CVSS 8.8, unsafe deserialization in Splunk Secure Gateway), CVE-2026-20252 (CVSS 7.6, SSRF in PDF export), and CVE-2026-20258 (CVSS 7.1, stored XSS in dashboards). All four share the same advisory. So CVE-2026-20253 is the one to address first: it has public exploit code and a direct path to host compromise.

No Workaround Exists Splunk confirmed there are no mitigations or workarounds for Splunk CVE-2026-20253. The only fix is patching. While you arrange the update, restricting network access to the PostgreSQL sidecar port reduces the exposure. That is a compensating control, not a fix.

Patched releases for self-hosted Splunk Enterprise are 10.2.4, 10.0.7, 10.4.0, 9.4.12, and 9.3.13. For Splunk Cloud Platform, the fixed builds are 10.4.2604.3, 10.3.2512.12, 10.2.2510.15, 10.1.2507.23, and 9.3.2411.132.

Why This Matters for Security Teams Splunk typically holds privileged access inside enterprise environments. The service ingests logs from every layer of the infrastructure, often holds long-term credentials used for pull-based data collection, and frequently runs with elevated OS-level permissions. When an attacker compromises the Splunk server, they get access to all of that.

Beyond the initial foothold, they gain a window into every system feeding Splunk data. That creates opportunities for lateral movement, credential harvesting, and log tampering to cover their tracks. So a compromised SIEM is not just one node: it is an observation deck over the rest of the network, with the added bonus of the ability to erase the evidence.

No confirmed in-the-wild exploitation of Splunk CVE-2026-20253 has been reported yet. But that window is closing. The combination of a CVSS 9.8 score and a public PoC makes this a high-value target. Threat actors typically move within days once working exploit code is public.

Prioritisation Guidance Check your Splunk Enterprise version now. If you run 10.0.x below 10.0.7 or 10.2.x below 10.2.4, treat this as an emergency patch. Confirm Splunk Cloud instances are on patched builds or open a case with Splunk support. Also use firewall rules to restrict access to the sidecar port in the interim while the update is applied.

Review Splunk server logs and the host filesystem for unexpected file creation before your patch date. That is a quick check for prior exploitation. Also verify that your Splunk process account does not have broader OS-level permissions than the job requires. Tightening that is a good baseline regardless of Splunk CVE-2026-20253 specifically.

How CVE-2026-20253 Turns Splunk’s PostgreSQL Sidecar Into an Open Door

Comments