CVE-2026-6658: nbconvert: stored XSS via unescaped Mermaid diagrams
UNKNOWN CISA: TRACK*nbconvert, the tool Jupyter uses to render notebooks as HTML, fails to escape `text/vnd.mermaid` cell output in its lab HTML template, letting an attacker break out of a `<pre>` tag and inject arbitrary JavaScript into any HTML export a victim opens. The blast radius depends entirely on how notebooks flow through your organization: any pipeline, internal wiki, data-science portal, or shared drive that auto-converts notebooks to HTML for review becomes a delivery mechanism for stored XSS against whoever views the export, and JupyterHub or notebook-sharing platforms that render user-submitted notebooks are the highest-risk exposure. There is no CISA KEV listing, no public exploit or Nuclei template, and EPSS sits near the bottom of the distribution (0.134%), so this is not being mass-exploited today — CISA's own SSVC decision is TRACK*, meaning monitor rather than act urgently. Patch nbconvert to the fixed release above 7.17.0 wherever notebooks are converted to HTML for viewing by others, and until then treat any HTML export served to a browser (especially through a shared Jupyter/JupyterHub instance) as untrusted content that should sit behind a strict Content-Security-Policy and, ideally, sandboxed rendering.
What is the risk?
Low-to-moderate risk in isolation: this is a classic reflected/stored XSS (CWE-79) requiring an attacker to get a crafted notebook cell rendered and a victim to open the resulting HTML — it is not remote code execution on the server and has no CVSS score, no KEV listing, and a near-floor EPSS score (0.00134). The realistic risk driver is exposure, not exploit sophistication: organizations that publish nbconvert-rendered HTML publicly, embed it in internal dashboards, or run multi-tenant JupyterHub/notebook-sharing services where users can upload arbitrary notebooks face a genuine session-hijack and credential-theft vector, since the JS runs in the viewer's browser context with whatever cookies/tokens that session holds. No public PoC or scanner signature exists yet (Top 97% EPSS percentile still reflects a very low absolute probability), so treat this as a patch-on-next-cycle item unless you specifically expose notebook HTML rendering to untrusted authors.
How does the attack unfold?
How severe is it?
What should I do?
1 step-
Upgrade nbconvert past 7.17.0 (the version noted as vulnerable) on any system that converts notebooks to HTML, including JupyterHub deployments, CI pipelines generating notebook artifacts, and static-site generators that embed notebook output. Until patched, avoid auto-rendering notebooks from untrusted or external authors into HTML that others will view; if HTML exports must be served, enforce a strict Content-Security-Policy (disallow inline script execution) on the pages/servers hosting them and serve exported HTML from a sandboxed origin/iframe with no access to session cookies of the main application. Detection: scan existing HTML exports for
data_mermaidblocks containing unescaped<,>, orscript/onerrorsequences that break out of the<pre>wrapper, and auditshare/templates/lab/base.html.j2usage in any custom nbconvert template forks.
What does CISA's SSVC say?
Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-6658?
nbconvert, the tool Jupyter uses to render notebooks as HTML, fails to escape `text/vnd.mermaid` cell output in its lab HTML template, letting an attacker break out of a `<pre>` tag and inject arbitrary JavaScript into any HTML export a victim opens. The blast radius depends entirely on how notebooks flow through your organization: any pipeline, internal wiki, data-science portal, or shared drive that auto-converts notebooks to HTML for review becomes a delivery mechanism for stored XSS against whoever views the export, and JupyterHub or notebook-sharing platforms that render user-submitted notebooks are the highest-risk exposure. There is no CISA KEV listing, no public exploit or Nuclei template, and EPSS sits near the bottom of the distribution (0.134%), so this is not being mass-exploited today — CISA's own SSVC decision is TRACK*, meaning monitor rather than act urgently. Patch nbconvert to the fixed release above 7.17.0 wherever notebooks are converted to HTML for viewing by others, and until then treat any HTML export served to a browser (especially through a shared Jupyter/JupyterHub instance) as untrusted content that should sit behind a strict Content-Security-Policy and, ideally, sandboxed rendering.
Is CVE-2026-6658 actively exploited?
No confirmed active exploitation of CVE-2026-6658 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-6658?
Upgrade nbconvert past 7.17.0 (the version noted as vulnerable) on any system that converts notebooks to HTML, including JupyterHub deployments, CI pipelines generating notebook artifacts, and static-site generators that embed notebook output. Until patched, avoid auto-rendering notebooks from untrusted or external authors into HTML that others will view; if HTML exports must be served, enforce a strict Content-Security-Policy (disallow inline script execution) on the pages/servers hosting them and serve exported HTML from a sandboxed origin/iframe with no access to session cookies of the main application. Detection: scan existing HTML exports for `data_mermaid` blocks containing unescaped `<`, `>`, or `script`/`onerror` sequences that break out of the `<pre>` wrapper, and audit `share/templates/lab/base.html.j2` usage in any custom nbconvert template forks.
What systems are affected by CVE-2026-6658?
This vulnerability affects the following AI/ML architecture patterns: MLOps / notebook-to-report pipelines, JupyterHub multi-tenant notebook platforms, Data science documentation/reporting sites.
What is the CVSS score for CVE-2026-6658?
No CVSS score has been assigned yet.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0049 Exploit Public-Facing Application AML.T0078 Drive-by Compromise Compliance Controls Affected
What are the technical details?
Original Advisory
A vulnerability in jupyter/nbconvert versions <= 7.17.0 allows for Cross-site Scripting (XSS) via unsanitized `text/vnd.mermaid` output in HTML exports. The `data_mermaid` block in `share/templates/lab/base.html.j2` renders `text/vnd.mermaid` cell output directly into HTML without escaping, enabling attackers to inject arbitrary HTML/JavaScript by breaking out of the `<pre>` tag. This vulnerability impacts any server using nbconvert to render notebooks as HTML, allowing attackers to execute arbitrary JavaScript in the context of users viewing the HTML export.
Exploitation Scenario
An attacker contributes or uploads a notebook (e.g., to a shared research repo, a JupyterHub multi-tenant environment, or an open-source project accepting notebook PRs) containing a cell whose `text/vnd.mermaid` output is crafted to close the `<pre>` tag early and inject a `<script>` payload. When a victim — a colleague, reviewer, or documentation-site visitor — opens the nbconvert-generated HTML export of that notebook, the injected JavaScript executes in their browser under the hosting page's origin, allowing the attacker to steal session cookies/tokens, pivot to the victim's JupyterHub session, or perform further actions (e.g., exfiltrating other notebooks, dashboard data, or credentials) using the victim's authenticated context.
Weaknesses (CWE)
CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') 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.
Timeline
Related Vulnerabilities
CVE-2025-59528 10.0 Flowise: Unauthenticated RCE via MCP config injection
Same attack type: Code Execution CVE-2024-2912 10.0 BentoML: RCE via insecure deserialization (CVSS 10)
Same attack type: Code Execution CVE-2023-3765 10.0 MLflow: path traversal allows arbitrary file read
Same attack type: Data Leakage CVE-2025-5120 10.0 smolagents: sandbox escape enables unauthenticated RCE
Same attack type: Data Leakage CVE-2026-21858 10.0 n8n: Input Validation flaw enables exploitation
Same attack type: Code Execution