The CVSS 7.1 rating for this stored XSS in Splunk Dashboard Studio obscures a significant trust boundary failure. The vulnerability allows any user with the 'power' role to embed malicious JavaScript in workflow actions within shared dashboards. When any authenticated user—administrators included—opens that dashboard and clicks 'Continue' on the workflow action, the payload executes in their session with their privilege level.
This is not a theoretical escalation. Power users have legitimate, persistent access to Dashboard Studio and can embed crafted workflow actions in dashboards they create or modify. The attack requires no special timing, no technical sophistication beyond standard dashboard authoring, and no presence at the moment of exploitation. A single malicious workflow action planted in a shared dashboard becomes a delayed-action munition: every admin who opens that dashboard in the weeks or months that follow detonates the payload automatically.
The CVSS user interaction metric treats the required click as a severity dampener, but this mischaracterizes the risk. Clicking 'Continue' on a workflow action is a routine workflow step in Splunk—a normal, expected interaction, not a suspicious anomaly that users are trained to avoid. The EPSS score of 0.00258 reflects the requirement for an authenticated account with specific role access, but it underweights how common power user accounts are in operational environments and how trivially the attack executes once the dashboard is in place.
What makes this noteworthy is what it reveals about Splunk's trust architecture. Role-based access control assumes boundaries between privilege levels prevent escalation. This XSS breaks that assumption. A mid-tier analyst role can execute arbitrary JavaScript in an administrator's browser, potentially exfiltrating session tokens, pivoting to other users, or triggering administrative actions available through Splunk Web.
What you should do: Audit your Splunk environment for dashboards authored by power users, particularly those shared across teams or marked as default views. Review workflow action configurations for suspicious URLs or unexpected JavaScript patterns. Consider implementing a review workflow for dashboards created or modified by power users before they become widely accessible. Restrict which roles can create or modify workflow actions if your Splunk deployment's role configuration permits such granularity. Monitor Splunk Web access logs for unusual patterns—particularly workflow action invocations with unexpected parameters or those targeting external domains.