Splunk Enterprise CVE-2026-76334

Exploitation requires the attacker to hold a valid Splunk account assigned the 'power' role - confirmed by CVSS PR:L. The attack cannot be executed by a standard low-privilege Splunk user or an unauthenticated external party. A separate, independently authenticated victim user must be social-engineered (phished) into navigating to the malicious workflow action in Dashboard Studio's Event Actions interface and actively clicking Continue - confirmed by CVSS UI:R and the CVE description's explicit statement that the 'power' role user cannot exploit the vulnerability at will. The specific vulnerable feature path is Dashboard Studio's workflow-action URL submission, which lacks sufficient input validation. Limiting factors: the attacker must already be a credentialed Splunk 'power'-role user; forced or automated triggering of the victim's action is not possible; no scope change occurs (S:U), meaning the injected SPL executes only within the victim's existing Splunk data permissions; non-default 'power' role assignment is required, so environments with minimal 'power'-role usage have reduced exposure.

The CVSS 3.1 score of 6.4 (Medium) with vector AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:N accurately reflects an attack that requires: attacker possession of a Splunk 'power' role (PR:L), high attack complexity due to the mandatory social-engineering step (AC:H), and active victim interaction (UI:R). Despite the high C and I sub-scores - indicating serious data exposure and modification potential - the real-world risk is meaningfully constrained by the multi-step dependency on phishing a second authenticated user. No EPSS probability data was supplied in the source intelligence, which limits quantitative exploitation forecasting and is a notable gap for prioritization decisions. The vulnerability carries no CISA KEV listing and no public POC is known at time of analysis, indicating no confirmed widespread or opportunistic exploitation. SSVC assessment: exploitation is not automatable (victim interaction cannot be forced); technical impact is partial-to-total on data within the victim's existing Splunk permission boundary but does not change scope (S:U). The combination of a required attacker role, mandatory social engineering, and victim click interaction positions this as a realistic insider-threat or targeted spear-phishing vector rather than a commodity scan-and-exploit risk - defenders should prioritize tightening 'power' role assignment over emergency patching timelines, though patching remains the definitive fix.

A Splunk user holding the 'power' role creates a Dashboard Studio workflow action containing injected SPL designed to read sensitive index data or modify saved searches accessible to a higher-privileged analyst. The attacker then social-engineers that analyst into selecting the malicious action from Event Actions within their browser session and clicking Continue, causing Splunk Enterprise to silently execute the injected SPL under the analyst's credentials and exfiltrate or alter data the attacker could not directly access. No public POC is known, so successful exploitation requires attacker familiarity with Splunk Dashboard Studio internals and direct access to the targeted Splunk environment.