Splunk Enterprise EUVD-2026-63129

The attacker must hold a valid, authenticated Splunk 'user' role account on the target Splunk Enterprise instance - unauthenticated exploitation is not possible based on the PR:L CVSS metric. The victim must also be an authenticated Splunk user who is actively tricked into opening the attacker's crafted Dashboard Studio dashboard link in their browser; the victim cannot be forced to do so (UI:R is mandatory). The vulnerable surface is specifically the Dashboard Studio ds.search data source mechanism - instances that have disabled Dashboard Studio or do not permit 'user'-role accounts to create or share dashboards have no exposure. The vendor explicitly notes that the 'user' role cannot exploit this at will, meaning the attack cannot be automated or triggered without the social engineering step. Exploitation is further bounded by the victim's data scope: the attacker can only reach data the victim user is authorized to access.

The CVSS 3.1 score of 8.0 (AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H) places this in the high-severity band, but the required user interaction (UI:R) and mandatory low-privilege account (PR:L) meaningfully distinguish it from unauthenticated, zero-click exploits. The attack is socially engineered rather than automated, constraining mass exploitation. No EPSS data was included in the source intelligence, preventing quantification of probabilistic exploitation likelihood. The vulnerability does not appear in the CISA KEV catalog and no public PoC is referenced in any of the provided intelligence sources - both are absent from available data rather than confirmed absent. Real-world risk scales directly with the sensitivity of data indexed in the Splunk environment: in a security operations context where Splunk ingests authentication logs, EDR telemetry, or financial records, a successful attack could expose an attacker-controlled 'user' account to the victim's entire data scope. The unchanged scope (S:U) means the attacker cannot pivot beyond the victim's Splunk session. Priority should be proportional to the breadth of data access held by likely victim accounts.

An internal threat actor holding a low-privileged Splunk 'user' role crafts a Dashboard Studio dashboard embedding malicious SPL designed to enumerate indexed data and exfiltrate results to an attacker-controlled lookup or external destination. The attacker delivers the dashboard link via a convincing internal phishing message - posing as a shared report or operational dashboard - to a Splunk power user or admin. When the victim opens the link in their browser, the attacker's SPL executes silently within the victim's authenticated session, reading data the attacker's own account cannot access and potentially disrupting search availability for other users.