Splunk Enterprise EUVD-2026-62893

Exploitation requires the attacker to already hold the Splunk 'power' role, a non-default but widely assigned role in production Splunk deployments for analysts, report authors, and dashboard builders - this is the PR:L prerequisite reflected in the CVSS vector. The attack additionally depends on successfully phishing a separate, already-authenticated Splunk user into initiating a browser-based PDF export of the malicious dashboard (UI:R); the attacker cannot trigger this export independently. The victim user must hold broader data permissions than the attacker for the injection to provide meaningful escalation. The vulnerable code path is specific to the PDF export workflow in Splunk Web - simply viewing a dashboard in the browser does not evaluate the injected SPL. Exploitation is bounded in scope to data accessible by the victim user's Splunk permissions, with no lateral movement to systems outside Splunk (S:U). The 'power' role assignment and the necessity of victim interaction are the two primary limiting factors that defenders should assess when estimating realistic exposure.

The CVSS 3.1 score of 6.7 (AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:L) reflects an accurate balance: the potential impact (C:H/I:H) is meaningful, but two chained prerequisites - holding the Splunk 'power' role and successfully phishing a separate authenticated victim - substantially constrain opportunistic or automated exploitation. The AC:H rating is warranted precisely because both conditions must be satisfied simultaneously, making mass exploitation unlikely. No EPSS data was provided in the intelligence sources, so probabilistic exploitation likelihood cannot be quantified numerically. Absence from the CISA KEV catalog and absence of public exploit code further support treating this as a targeted rather than widespread threat. The vulnerability is best understood as an insider-threat or compromised-analyst vector: the 'power' role is routinely assigned to SOC analysts and report builders, and a mid-sized enterprise security operations team relying on Splunk dashboards shared across trust boundaries should still treat this as an actionable remediation priority given the C:H/I:H impact on sensitive log and operational data.

An insider or compromised account holding the Splunk 'power' role authors a shared dashboard embedding SPL designed to read sensitive search results from restricted indexes and write them to a world-readable lookup table. The attacker then sends a targeted phishing message - for example, a fabricated 'executive report request' - to a SOC manager whose Splunk account has access to those restricted indexes, prompting them to open the dashboard in their browser and click 'Export as PDF'. Splunk Enterprise executes the injected SPL under the manager's permissions, granting the attacker read and modification access to data well beyond their own authorization scope. No public proof-of-concept code has been identified at time of analysis.