Splunk Enterprise CVE-2026-76325

The attacker must hold the Splunk 'power' built-in role on the target Splunk Enterprise instance - this is a non-default privilege level above standard users and must be explicitly granted by an administrator. The attack requires the ability to create and share knowledge objects at the app level, a capability gated to the 'power' role. A second, separately authenticated Splunk user must visit a standard Splunk Web page that triggers auto-tour resolution for the poisoned page name - the victim's visit is the execution trigger. Exploitation is limited to the authenticated victim's session context: the JavaScript executes with the victim's permissions, not an elevated or system-level context, and scope is unchanged (S:U). The attack does not require any specific non-default Splunk configuration beyond the 'power' role being assigned; any default Splunk Web deployment with auto-tours enabled is susceptible once the precondition of attacker role access is met.

The CVSS 3.1 vector AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:N scores 7.3 (High). The most significant limiting signal is the dual-actor requirement: the attacker must hold the Splunk 'power' role (PR:L) to write the malicious object, AND a second authenticated victim must visit a relevant Splunk Web page (UI:R). This is not an unauthenticated or opportunistic attack - it requires insider access or a compromised 'power' account as a precondition. However, once staged, the attack is passive and persistent: any authenticated user who navigates to the poisoned page will execute the payload without further attacker interaction, and the JavaScript runs under the victim's session permissions (C:H, I:H). There is no EPSS score in the provided data, no CISA KEV listing, and no public proof-of-concept identified. The risk is highest in environments where 'power' role is broadly granted or where Splunk is used by high-privilege users (SOC analysts, incident responders) whose session tokens would be especially valuable. The absence of availability impact (A:N) and the scoped impact (S:U) limit blast radius to the victim's own session context.

An attacker with a 'power' role account - either a malicious insider or a threat actor who has compromised such an account - crafts a ui-tour knowledge object containing a JavaScript payload, names it to match an existing auto-tour page (such as a default Splunk dashboard page), and shares it at the app level. When a SOC analyst or administrator with higher permissions subsequently visits that Splunk Web page in the course of normal operations, the malicious tour content is resolved from the app namespace and the JavaScript executes silently in their browser, potentially exfiltrating session tokens, search results, or Splunk configuration data within the scope of the victim's permissions. No public proof-of-concept has been identified at time of analysis.