Splunk Enterprise EUVD-2026-62911

The attacker must already hold the Splunk 'power' role on the target Splunk Enterprise instance - this is not an unauthenticated or external network attack. The 'power' role is a non-default elevated role that must be explicitly assigned by an administrator, per Splunk's role-based access control model. Exploitation further requires successfully social-engineering a target user into navigating to the malicious dashboard within their authenticated Splunk Web browser session; the attacker cannot trigger execution autonomously or programmatically. Maximum impact - full data access and admin-level action execution - is contingent on the victim holding the 'admin' Splunk role; a non-admin victim yields a lower-severity XSS outcome scoped to that user's data permissions. Deployments where 'power' role is tightly restricted, where admins do not routinely browse dashboards authored by other users, and where Content Security Policy headers limit inline script execution are at materially reduced practical risk.

The official CVSS score of 5.4 (Medium) accurately captures the meaningful prerequisites: the attacker must already hold the 'power' Splunk role (PR:L) and must successfully phish a target user (UI:R, AC:H) to trigger payload execution. Despite this friction, the potential impact is severe when the victim holds admin privileges - full read access to all Splunk-indexed data and the ability to invoke actions under admin permissions. No EPSS data was included in the input, and this CVE does not appear in the CISA KEV, so observed in-the-wild exploitation is not confirmed. The practical risk is strongly shaped by role hygiene: organizations where 'power' role membership is broad or loosely governed, and where admins routinely review dashboards created by peers, face substantially higher exposure than those with tight access controls. The absence of KEV listing and the phishing dependency support treating this as a scheduled patch cycle priority rather than an emergency response, though the admin-escalation path warrants prompt attention in environments with shared dashboard cultures.

An attacker who already holds the Splunk 'power' role creates or modifies a shared dashboard, embedding a malicious JavaScript payload within a sparkline panel's tooltip format options. The attacker then sends a Splunk admin a plausible pretext message - for example, asking them to review a new operational dashboard - causing the admin to open it in their authenticated browser session. The injected script executes in the admin's browser context, capable of exfiltrating session tokens, reading sensitive indexed data, or issuing Splunk REST API calls with full administrative privileges. No public proof-of-concept code is known at time of analysis.