CVE-2026-20258: Splunk: stored XSS hijacks dashboards via HTML panel

MEDIUM
Published June 10, 2026
CISO Take

A low-privileged attacker with any valid Splunk account can embed persistent malicious JavaScript in a classic dashboard HTML panel, which then silently executes in the browser of any targeted user who is phished into loading that dashboard. For organizations relying on Splunk as their ML monitoring backbone or SOC analytics layer, a successful hit against an admin or power user results in full session hijacking — granting the attacker unrestricted access to all search indexes, including AI/ML telemetry, model output logs, and security event data. No public exploits exist and the CVE is absent from CISA KEV, but the CVSS 7.1 high rating and Splunk's privileged position in enterprise security operations justify prompt action. Patch to Splunk Enterprise ≥10.2.4 / 10.0.7 / 9.4.12 / 9.3.13 or the corresponding Splunk Cloud Platform versions; as an interim control, restrict the `edit_dashboard` capability to admin and power roles only.

Sources: NVD ATLAS

What is the risk?

Medium-high risk in AI/ML monitoring environments. Attack complexity is rated high due to the mandatory phishing prerequisite, but Splunk's role as a central SIEM and ML analytics platform makes it an exceptionally attractive pivot point. A compromised admin session exposes all indexed data and can silence alerting rules — effectively blinding the security team. The low-privilege initial access bar increases insider threat and supply-chain risk for organizations with broad Splunk user populations. Exploitation probability is currently low given no public PoC, but the social-engineering vector is trivial to operationalize by motivated adversaries.

How does the attack unfold?

Persistent Payload Injection
Low-privileged attacker with a valid Splunk account creates or edits a classic dashboard and stores malicious JavaScript inside an HTML panel, making the payload persistent and shared with all viewers.
AML.T0049
Phishing Delivery
Attacker sends a phishing message (email, Slack, Teams) to a Splunk admin or power user with a direct URL to the malicious dashboard, framed as a shared ML anomaly report or operational alert requiring review.
AML.T0052
Browser-Side Execution
Victim loads the dashboard in their authenticated browser session, triggering the stored JavaScript payload which executes silently in the Splunk application context and exfiltrates the victim's session token to an attacker-controlled server.
AML.T0011.003
Session Hijack and Full Data Access
Attacker replays the captured session token to authenticate as the admin, gaining unrestricted access to all Splunk search indexes including AI/ML telemetry, model output logs, and security events, with the ability to disable alerting rules and pivot to connected integrations.
AML.T0025

How severe is it?

CVSS 3.1
5.4 / 10
EPSS
0.2%
chance of exploitation in 30 days
Higher than 15% of all CVEs
Exploitation Status
No known exploitation
Sophistication
Moderate

What is the attack surface?

AV AC PR UI S C I A
AV Network
AC Low
PR Low
UI Required
S Changed
C Low
I Low
A None

What should I do?

5 steps
  1. Patch: upgrade Splunk Enterprise to ≥10.2.4, ≥10.0.7, ≥9.4.12, or ≥9.3.13; Splunk Cloud Platform to ≥10.3.2512.11, ≥10.2.2510.15, ≥10.1.2507.23, or ≥9.3.2411.132.

  2. Interim: remove edit_dashboard capability from all non-admin/non-power roles to prevent low-priv users from creating or modifying classic HTML panels.

  3. Audit: search existing classic dashboards for suspicious HTML panel content — look for raw <script> tags, event handler attributes (onerror, onload, onclick), javascript: URIs, and Base64-encoded blobs.

  4. Harden: enforce Content Security Policy headers on your Splunk web reverse proxy to restrict inline script execution.

  5. Detect: alert on dashboard edits performed by low-priv accounts and correlate with phishing indicators; review Splunk audit logs (_audit index) for unexpected edit_dashboard actions.

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act
Art. 15 - Accuracy, robustness and cybersecurity Art. 9 - Risk management system
ISO 42001
A.8.4 - Robustness and security of AI systems A.9.4 - Access control for AI systems
NIST AI RMF
MANAGE 2.2 - Mechanisms are in place to manage AI risks
OWASP LLM Top 10
LLM08:2025 - Excessive Agency

Frequently Asked Questions

What is CVE-2026-20258?

A low-privileged attacker with any valid Splunk account can embed persistent malicious JavaScript in a classic dashboard HTML panel, which then silently executes in the browser of any targeted user who is phished into loading that dashboard. For organizations relying on Splunk as their ML monitoring backbone or SOC analytics layer, a successful hit against an admin or power user results in full session hijacking — granting the attacker unrestricted access to all search indexes, including AI/ML telemetry, model output logs, and security event data. No public exploits exist and the CVE is absent from CISA KEV, but the CVSS 7.1 high rating and Splunk's privileged position in enterprise security operations justify prompt action. Patch to Splunk Enterprise ≥10.2.4 / 10.0.7 / 9.4.12 / 9.3.13 or the corresponding Splunk Cloud Platform versions; as an interim control, restrict the `edit_dashboard` capability to admin and power roles only.

Is CVE-2026-20258 actively exploited?

No confirmed active exploitation of CVE-2026-20258 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-20258?

1. Patch: upgrade Splunk Enterprise to ≥10.2.4, ≥10.0.7, ≥9.4.12, or ≥9.3.13; Splunk Cloud Platform to ≥10.3.2512.11, ≥10.2.2510.15, ≥10.1.2507.23, or ≥9.3.2411.132. 2. Interim: remove `edit_dashboard` capability from all non-admin/non-power roles to prevent low-priv users from creating or modifying classic HTML panels. 3. Audit: search existing classic dashboards for suspicious HTML panel content — look for raw `<script>` tags, event handler attributes (`onerror`, `onload`, `onclick`), `javascript:` URIs, and Base64-encoded blobs. 4. Harden: enforce Content Security Policy headers on your Splunk web reverse proxy to restrict inline script execution. 5. Detect: alert on dashboard edits performed by low-priv accounts and correlate with phishing indicators; review Splunk audit logs (`_audit` index) for unexpected `edit_dashboard` actions.

What systems are affected by CVE-2026-20258?

This vulnerability affects the following AI/ML architecture patterns: ML monitoring dashboards, AI/ML analytics and observability platforms, SOC/SIEM with ML-powered detection, MLOps pipeline observability.

What is the CVSS score for CVE-2026-20258?

CVE-2026-20258 has a CVSS v3.1 base score of 5.4 (MEDIUM). The EPSS exploitation probability is 0.24%.

What is the AI security impact?

Affected AI Architectures

ML monitoring dashboardsAI/ML analytics and observability platformsSOC/SIEM with ML-powered detectionMLOps pipeline observability

MITRE ATLAS Techniques

AML.T0011.003 Malicious Link
AML.T0025 Exfiltration via Cyber Means
AML.T0036 Data from Information Repositories
AML.T0049 Exploit Public-Facing Application
AML.T0052 Phishing

Compliance Controls Affected

EU AI Act: Art. 15, Art. 9
ISO 42001: A.8.4, A.9.4
NIST AI RMF: MANAGE 2.2
OWASP LLM Top 10: LLM08:2025

What are the technical details?

Original Advisory

In Splunk Enterprise versions below 10.2.4, 10.0.7, 9.4.12, and 9.3.13, and Splunk Cloud Platform versions below 10.3.2512.11, 10.2.2510.15, 10.1.2507.23, and 9.3.2411.132, a low-privileged user that does not hold the "admin" or "power" Splunk roles could store a malicious script in a classic dashboard HTML panel, causing unauthorized JavaScript code to execute in the browser of another user. The vulnerability requires the attacker to phish the victim by tricking them into initiating a request within their browser. The low-privileged user should not be able to exploit the vulnerability at will.

Exploitation Scenario

An attacker holding a low-privileged Splunk account — obtained via credential stuffing, phishing, or a shared service account — navigates to a classic dashboard and inserts a JavaScript payload into an HTML panel. The script, disguised as a benign widget, exfiltrates the viewer's session cookie to an attacker-controlled endpoint. The attacker then crafts a plausible internal message (Slack, Teams, or email) to a Splunk admin, framed as a shared ML anomaly report requiring review, with a direct URL to the malicious dashboard. When the admin opens the link, the payload fires in their authenticated browser context, silently POSTing the session token to the attacker. The attacker replays this token to assume the admin identity, accesses all search indexes including AI/ML model telemetry and security events, disables alerting rules to cover tracks, and pivots to connected SOAR or data pipeline integrations using valid Splunk API credentials.

Weaknesses (CWE)

CWE-79 — Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'): The product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.

  • [Architecture and Design] Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482]. Examples of libraries and frameworks that make it easier to generate properly encoded output include Microsoft's Anti-XSS library, the OWASP ESAPI Encoding module, and Apache Wicket.
  • [Implementation, Architecture and Design] Understand the context in which your data will be used and the encoding that will be expected. This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages. Study all expected communication protocols and data representations to determine the required encoding strategies. For any data that will be output to another web page, especially any data that was received from external inputs, use the appropriate encoding on all non-alphanumeric characters. Parts of the same output document may require different encodings, which will vary depending on whether the output is in the: etc. Note that HTML Entity Encoding is only appropriate for the HTML body. Consult the XSS Prevention Cheat Sheet [REF-724] for more details on the types of encoding and escaping that are needed. HTML body Element attributes (such as src="XYZ") URIs JavaScript sections Casca

Source: MITRE CWE corpus.

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N

Timeline

Published
June 10, 2026
Last Modified
June 15, 2026
First Seen
June 10, 2026

Related Vulnerabilities