Splunk Enterprise EUVD-2026-107653

Exploitation requires (1) a Splunk Enterprise version below 10.4.4 or below 10.2.8, (2) a search head cluster (SHC) deployment where the PostgreSQL sidecar service is running, and (3) a valid but low-privileged Splunk account that does NOT hold the 'admin' or 'power' roles. The concrete prerequisite named in the description is that the SHC identifier appears in search job logs the user can read, from which the sidecar's privileged database password is deterministically derived. Limiting factors: the attacker must be authenticated (PR:L), and the flaw is confined to search head cluster members running the sidecar - standalone or non-SHC Splunk deployments and versions at/above the fixed releases are not exposed. No user interaction and no elevated role are required beyond basic authenticated access.

This is a credible operational priority for any organization running Splunk Enterprise in a search head cluster (SHC) configuration, though not an emergency across all Splunk deployments. The vendor CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N) and score of 8.8 indicate a network-reachable, low-complexity attack requiring only low privileges - consistent with the description, which states any authenticated user WITHOUT the 'admin' or 'power' roles can exploit it. The high-privilege outcome (C:H/I:H/A:H) is justified: deriving the PostgreSQL sidecar superuser password yields arbitrary OS command execution as the Splunk service account, a full privilege escalation from a low-rights application user to host-level code execution. CWE-321 (use of a hard-coded/derivable cryptographic key) matches the root cause - the DB password is deterministically derived from the SHC identifier that leaks into search job logs. Mitigating the urgency: there is no KEV listing, no public exploit code identified, and no EPSS score provided, so there is currently no evidence of active or widespread exploitation. The attack is also scoped to SHC members with the PostgreSQL sidecar in use, not every Splunk instance. Note one metric worth verifying: the vendor rated Scope Unchanged (S:U), but because the exploit crosses from the Splunk authorization context to arbitrary OS command execution on the host account, a Scope Changed (S:C) argument is defensible - verify with Splunk if precise scoring matters.

A low-privileged but authenticated Splunk user (lacking admin/power roles) on a search head cluster inspects search job logs, which expose the search head cluster identifier. Because the PostgreSQL sidecar derives its superuser password from that identifier, the attacker reconstructs the password, connects to the sidecar database, and leverages it to run arbitrary operating system commands as the account running Splunk Enterprise. No public proof-of-concept exploit has been identified at the time of analysis, but the described technique is deterministic and does not require special timing or user interaction.