This is a stored XSS in Splunk's sparkline tooltip rendering, and it is more dangerous than the CVSS 5.7 suggests. The attack works by embedding malicious JavaScript in a dashboard that a low-privilege user creates; when a privileged user hovers over a sparkline cell in that dashboard, the payload executes in the privileged user's browser context with access to their session cookies, localStorage, and DOM. No malicious link, no social engineering — just a dashboard that looks useful enough to inspect.
The privilege escalation dimension is the critical piece that makes this a priority even at medium severity. In Splunk deployments, 'low-privilege' does not mean 'limited data access' — it means 'non-admin.' A standard Splunk user often has read access to authentication events, failed logins, privileged account activity, and compliance data. The users most likely to hover over sparklines in shared dashboards are power analysts and sometimes SOC staff. This means a low-privilege attacker can target the security team itself — the defenders become the compromised.
This is not an isolated flaw. The same tooltip XSS pattern has appeared in Tableau, Grafana, Kibana, Power BI, and internal dashboard frameworks across the industry. Each gets patched in isolation, but the underlying rendering path — tooltip content inheriting page context without independent escaping — keeps recurring. Treat this as evidence of a class vulnerability in dashboard products, not a one-off implementation error.
Check your Splunk version: affected branches are below 10.4.2, 10.2.6, 10.0.9, and 9.4.14. If you run older release trains, this vulnerability has been sitting unpatched in your environment. Beyond patching, review your dashboard sharing permissions model: dashboards are not inert files, they are privilege transfer mechanisms. Assume any JavaScript embedded in a shared dashboard will execute in the context of whoever views it.