Splunk Enterprise EUVD-2026-63125

The attacker must hold an authenticated Splunk Enterprise account assigned a role that includes the schedule_search capability; this is not a default capability for all Splunk users and must be explicitly granted by an administrator, per Splunk's role-capability documentation referenced in the CVE description. The attack additionally requires a second user (the victim) to open the crafted alert link, satisfying the UI:R condition in the CVSS vector - unauthenticated or zero-click exploitation is not possible. Exploitation is further limited to Splunk Enterprise deployments running affected version branches (9.4 below 9.4.14, 10.0 below 10.0.9, 10.2 below 10.2.6, 10.4 below 10.4.2). Scope is not changed (S:U), so the script is confined to the victim's Splunk browser session and cannot directly pivot to other systems. Integrity and availability of Splunk data are not impacted; only confidentiality of the victim's accessible data is at risk.

The CVSS 3.1 vector CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:N/A:N yields a base score of 5.7 (Medium), and the individual metrics tell a nuanced story: PR:L confirms the attacker must hold an authenticated Splunk account with the schedule_search capability, UI:R requires a victim to click the crafted link, and C:H reflects that all Splunk data accessible to the victim is at risk. These two constraints - authenticated attacker and required user interaction - meaningfully reduce real-world exploitability compared to an unauthenticated or zero-click XSS. No EPSS score was provided in the intelligence data, and no CISA KEV listing is present, so exploitation probability cannot be quantified beyond inference. No public POC has been reported. The SSVC signals are consistent with a 'Track' or 'Attend' posture: exploitation is not confirmed automated, requires insider or socially-engineered access, and technical impact is limited to confidentiality within the scope of the victim's session. For organizations where Splunk users have broad access to sensitive security data - which is the common enterprise deployment model - the confidentiality impact of a successful attack is high even if the attack path requires social engineering.

An attacker holding a Splunk account with the schedule_search capability crafts a JavaScript payload and embeds it in an alert trigger condition threshold field, which Splunk Web stores unescaped. The attacker then sends the alert link to a security analyst or Splunk administrator, who opens it in their browser; the stored script executes in the victim's authenticated session and silently exfiltrates search results, dashboards, tokens, or other data accessible to that user. No public POC has been identified, but the attack primitive - stored XSS via unescaped user input in a web UI - is well-understood and reproducible by any attacker familiar with browser-based exploitation.