Splunk Enterprise EUVD-2026-62898

The attacker must hold an authenticated Splunk account assigned the 'power' role - a non-admin but privileged built-in role - to store the malicious workflow action URL in Dashboard Studio. A completely separate authenticated Splunk user (the victim) must then navigate to Event Actions, select the attacker's stored action, and explicitly click 'Continue.' The description explicitly states the 'power' role user cannot exploit this at will: the victim's deliberate interaction is mandatory, making social engineering (phishing within the Splunk UI) a hard prerequisite. Exploitation is therefore limited to scenarios of insider threat, compromised 'power' role accounts, or targeted phishing of Splunk users. The attack does not work against unauthenticated users and does not self-propagate. Both actors must have network access to the same Splunk Web instance.

The vendor-assigned CVSS 7.1 with vector AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H reflects the layered prerequisites accurately. AC:H is appropriate because exploitation is not a single-step network attack - the attacker must first store the payload (requiring the 'power' role, hence PR:L) and then successfully phish a second authenticated user into triggering it (hence UI:R). The S:U (Unchanged scope) correctly limits blast radius to data and actions available within the victim's Splunk Web session. The A:H rating from the official vector is debatable: a stored XSS does not inherently disrupt availability unless the attacker's JavaScript actively deletes stored searches, dashboards, or configurations at scale - plausible in Splunk given its data-rich environment, but not confirmed by the description alone. No EPSS data is provided in the input, so exploitation probability cannot be quantified. The vulnerability is not listed in CISA KEV and no POC has been identified, suggesting no widespread in-the-wild activity. Real-world risk is moderate-to-elevated for organizations where 'power' role accounts are broadly distributed or where insider threat is a concern, but this is not a zero-interaction remotely exploitable flaw.

A malicious insider or attacker with a compromised 'power' role account opens Dashboard Studio and creates a workflow action whose URL embeds a JavaScript payload. The attacker then socially engineers a higher-privileged Splunk user - such as an admin - into opening the relevant dashboard, navigating to Event Actions, selecting the poisoned action, and clicking Continue. The victim's browser executes the attacker's script in the context of their authenticated Splunk Web session, enabling session token theft, unauthorized searches, data exfiltration, or further pivot within Splunk. No public exploit code has been identified at time of analysis.