Splunk Enterprise EUVD-2026-36081

The attacker must hold a valid low-privileged Splunk account that does not have the 'admin' or 'power' role. The classic dashboard feature must be in use - this vulnerability does not affect Splunk's newer dashboard framework. A higher-privileged user (admin or power role) must be induced or naturally navigate to view the crafted dashboard in their browser session, satisfying the UI:R condition. Exploitation is limited by: (1) the requirement for at least a low-privileged authenticated Splunk account, eliminating unauthenticated external attackers; (2) mandatory victim interaction - the privileged user must actively view the malicious dashboard; (3) the attack targets confidentiality only (C:H, I:N, A:N), so it cannot be used to modify data or disrupt availability. The primary risk scenario is a malicious insider or a compromised low-privileged account in a multi-tenant or large-team Splunk deployment.

The CVSS base score of 5.7 (Medium) reflects the required user interaction (UI:R) and low-privilege prerequisite (PR:L), which temper what would otherwise be a more severe rating given the C:H confidentiality impact. The attack complexity is low (AC:L) and the attack vector is network (AV:N), meaning no physical access or special timing is needed once the attacker holds any low-privileged Splunk account. The S:U (unchanged scope) rating means the impact is contained to the victim's Splunk session rather than expanding to the underlying host. No EPSS score was provided in the source data, and the vulnerability is not listed in CISA KEV, indicating no confirmed active exploitation at time of analysis. No public proof-of-concept code has been identified. Despite the medium CVSS, the practical risk in environments where low-privileged users share dashboard visibility with administrators is elevated: the high confidentiality impact combined with a trivial exploitation path (craft a dashboard, wait for an admin to view it) suggests real-world risk exceeds the numeric score for organizations with mixed-trust Splunk user populations or third-party dashboard contributors.

An attacker with a low-privileged Splunk account crafts a classic dashboard embedding CSS injection payloads in inline style attributes - for example, using a CSS url() directive pointing to an attacker-controlled server - then saves or shares the dashboard in a location accessible to administrative users. When a higher-privileged user opens the dashboard in their browser, their Splunk session triggers the CSS-driven outbound request, potentially transmitting session tokens or credential material to the attacker's server. No public proof-of-concept has been identified, but the technique relies entirely on standard browser CSS processing behavior, making independent replication straightforward for an attacker with basic web knowledge.