Orca Security researchers have disclosed a critical remote code execution vulnerability in Splunk Enterprise that bypasses all application-level authentication by targeting a PostgreSQL sidecar service exposed by the Splunk platform on a non-standard port. CVE-2026-20253, rated CVSS 9.8, allows an unauthenticated attacker with network access to Splunk Enterprise hosts to execute arbitrary code — a severe outcome given that SIEM platforms receive, process, and store security event data from across the organisation’s entire monitoring estate.
Vulnerability Details
The vulnerability stems from Splunk Enterprise’s use of a PostgreSQL sidecar process — an internal data store supporting certain Splunk platform features — that binds to a network port without enforcing authentication equivalent to the main Splunk interface. Orca Security researchers identified that this sidecar service could be reached directly on the network, bypassing Splunk’s own authentication layer entirely.
By sending crafted database queries to the sidecar service, an unauthenticated attacker can trigger file operations that result in arbitrary code execution on the Splunk Enterprise host operating system. On Linux deployments, this yields execution under the splunk service account; on Windows, under the configured Splunk service account — which in many enterprise deployments carries elevated privileges for log collection access across remote hosts.
Affected versions:
- Splunk Enterprise 9.2.x and earlier (Windows and Linux)
- Splunk Cloud Platform is not affected — the managed environment does not expose the PostgreSQL sidecar externally
Fixed version: Splunk Enterprise 9.3.0
Why SIEM Compromise Is Especially Consequential
The impact of compromising a SIEM server extends considerably beyond a typical RCE scenario. Splunk Enterprise in most enterprise deployments simultaneously:
- Receives event data from every critical system across the environment — firewalls, Active Directory, endpoints, identity providers, and cloud platforms
- Stores the security event history that represents an organisation’s complete picture of past network activity and user behaviour
- Runs the threat detection searches and correlation rules that, if disabled or manipulated, would blind the SOC to active intrusions elsewhere in the environment
- Holds credentials for log source connections, forwarder authentication tokens, and integration APIs
An attacker who achieves code execution on a Splunk Enterprise server can extract raw security event logs to map the organisation’s detection coverage, identify gaps, disable or modify detection rules to suppress visibility into their own activity, and extract credentials stored in forwarder authentication configurations. For organisations under active intrusion from a sophisticated threat actor, a compromised SIEM represents an intelligence catastrophe — the attacker gains complete visibility into the defender’s detection capability while maintaining the ability to suppress alerts.
Assessing Exposure
Splunk Enterprise hosts typically bind multiple ports: the web interface (TCP/8000), REST API and management interface (TCP/8089), Splunk-to-Splunk forwarding (TCP/9997), and internal sidecar services. Security teams should verify which ports are accessible from which network segments and confirm that Splunk hosts are not accessible from workstation or general server VLANs.
Recommended Actions
- Patch immediately — upgrade to Splunk Enterprise 9.3.0; a CVSS 9.8 no-authentication RCE on your SIEM does not admit delay regardless of patching window constraints
- Firewall Splunk hosts at the network layer — restrict inbound connections to Splunk management ports (TCP/8089, TCP/8000) and the PostgreSQL sidecar port to authorised Splunk search heads, forwarders, and administrative source addresses only
- Audit Splunk host network exposure — run a port scan against Splunk Enterprise hosts to confirm which ports are network-accessible and from which segments; any unexpected exposure should be treated as a potential breach indicator
- Review Splunk process logs for evidence of unexpected connections to the PostgreSQL sidecar port over the past 90 days — exploitation activity may predate the public disclosure
- Validate detection rule integrity — if Splunk may have been compromised, export and review the current detection rule set against a known-good baseline before trusting any future alerts
- Rotate Splunk service credentials following patching — forwarder authentication tokens, REST API credentials, and any credentials stored in Splunk knowledge objects should be refreshed as a precaution
Share this article