Splunk Enterprise CVE-2026-76348

Exploitation requires an authenticated Splunk user account assigned to a role that includes the list_search_head_clustering capability, which Splunk describes as a high-privilege permission. The Splunk Enterprise deployment must be configured in Search Head Cluster mode - the vulnerable endpoints are specific to SHC and do not exist in standalone instances. The attacker must have network-level access to the Splunk Search Head Cluster member control endpoints. Exploitation is hard-bounded by the authentication requirement: unauthenticated users and users with only standard (non-clustering) roles cannot trigger this vulnerability. Non-clustered Splunk deployments are entirely unaffected regardless of user permissions.

The CVSS 3.1 score of 3.8 (Low) accurately reflects the constrained attack surface: while the endpoint is network-reachable (AV:N) with low complexity (AC:L), exploitation requires prior authentication with a high-privilege Splunk role (PR:H), substantially narrowing the attacker population to insiders or actors who have already compromised a privileged account. The impact is limited to minor integrity (I:L) and availability (A:L) degradation - specifically, unauthorized cluster state changes causing service disruption - with no confidentiality exposure (C:N). No EPSS score was present in the source data, so exploitation probability cannot be quantified; the absence of KEV listing and POC further suggests this has not been observed in active campaigns. The real-world risk profile is that of an insider threat or post-breach lateral movement step: an attacker who has escalated to a role with SHC clustering capabilities could destabilize cluster availability as a secondary impact. Even a well-staffed enterprise SOC team should treat this as a low-urgency patch item rather than an emergency, though environments with broadly distributed high-privilege Splunk roles or multi-tenant deployments face proportionally higher exposure. CVSS signal and description are consistent - no contradictions in available data.

An insider or attacker who has compromised a Splunk account bearing the list_search_head_clustering capability issues crafted HTTP GET (or other read-typed) requests to Search Head Cluster member control endpoints that are designed to accept only state-changing verbs. Because the endpoints apply read-only authorization without verifying the HTTP method, the requests are processed as state changes, altering cluster membership or configuration and disrupting Search Head Cluster availability. No public POC has been identified, but the mechanism is clearly described and technically straightforward for anyone with the prerequisite access.