Splunk Enterprise EUVD-2026-107654

Exploitation requires a specific, non-default alignment of conditions: (1) the target Splunk Enterprise deployment must have federated search configured with one or more federated providers whose disabling has operational impact; (2) the phished victim must be currently authenticated and must hold a role granting the edit_federated_providers capability - an administrative capability not held by ordinary users; and (3) the victim must actively perform the attacker-directed browser action (clicking a crafted link), since the unauthenticated attacker cannot trigger the request at will. The underlying enabler is that the federated provider REST API accepts GET requests for provider-state-changing actions, allowing a cross-site forged request. Limiting factors that reduce real-world risk: mandatory user interaction (UI:R), the requirement that the victim hold a rare privileged capability, high attack complexity, and an impact confined to temporarily disabling federated searches (no confidentiality loss, no persistence, no remote code execution).

This is a genuinely low-to-moderate priority issue despite being network-reachable. The CVSS 3.1 base score is 4.2 (Medium), and the vector CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:L is internally consistent with the description: it is a CSRF flaw (CWE-352) where the attacker themselves holds no credentials (PR:N) but success depends entirely on social-engineering a specific privileged user into clicking an attacker-supplied link (UI:R), and the technical impact is limited to low integrity and low availability with no confidentiality loss (C:N/I:L/A:L). The high attack complexity (AC:H) reflects that the attacker cannot exploit at will - they must successfully phish a user who both is authenticated and holds the edit_federated_providers capability, a comparatively rare role. No EPSS score, CISA KEV listing, or public POC was provided in the input, so exploitation probability signals are absent rather than contradictory; by the precision rules this means no public exploit is identified at time of analysis, and there is no evidence of active exploitation. The impact ceiling is also low: successful exploitation only *temporarily* disables federated search data retrieval, not data theft or persistent compromise. In short, the signals are consistent (not conflicting) and all point to a real but low-severity availability/integrity nuisance rather than a widespread or urgent threat. Missing data to note: no EPSS, KEV, or POC indicators were supplied, so forward-looking exploitation likelihood cannot be quantified.

An attacker crafts a malicious web page or email link that issues a GET request to the Splunk federated provider REST API, then phishes a logged-in administrator who holds the edit_federated_providers capability into opening it in their authenticated browser session. Because the API accepts state-changing GET requests, the forged request silently turns off all federated search providers, temporarily breaking federated searches against remote datasets. No public exploit code is identified in the provided data, and the high attack complexity means the attacker must both reach and deceive a specifically privileged user.