CVE-2026-6658: nbconvert: stored XSS via unescaped Mermaid diagrams

UNKNOWN CISA: TRACK*
Published June 26, 2026
CISO Take

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.

Sources: NVD EPSS huntr.com ATLAS

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?

Malicious notebook creation
Attacker crafts a notebook cell with a `text/vnd.mermaid` output containing a payload that breaks out of the `<pre>` tag in the HTML export template.
AML.T0011.000
Distribution / hosting
The notebook is submitted to a shared repo, uploaded to a multi-tenant JupyterHub, or otherwise placed where nbconvert will render it to HTML for others.
Victim views HTML export
A user opens the nbconvert-generated HTML page, triggering the unescaped script to execute in their browser session.
AML.T0078
Session/data compromise
The injected JavaScript steals cookies/tokens or performs actions as the victim, potentially pivoting into their Jupyter/JupyterHub session or other connected data.

How severe is it?

CVSS 3.1
N/A
EPSS
0.1%
chance of exploitation in 30 days
Higher than 3% of all CVEs
Exploitation Status
Exploit Available
Exploitation: MEDIUM
Sophistication
Moderate
Exploitation Confidence
medium
CISA SSVC: Public PoC
Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What should I do?

1 step
  1. 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 does CISA's SSVC say?

Decision Track*
Exploitation poc
Automatable No
Technical Impact partial

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:

EU AI Act
Article 15 - Accuracy, robustness and cybersecurity
ISO 42001
A.6.2 (AI system development) - Secure development lifecycle for AI systems
NIST AI RMF
MANAGE 2.1 - Ongoing monitoring and management of AI system risks

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

MLOps / notebook-to-report pipelinesJupyterHub multi-tenant notebook platformsData science documentation/reporting sites

MITRE ATLAS Techniques

AML.T0049 Exploit Public-Facing Application
AML.T0078 Drive-by Compromise

Compliance Controls Affected

EU AI Act: Article 15
ISO 42001: A.6.2 (AI system development)
NIST AI RMF: MANAGE 2.1

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'): 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

Published
June 26, 2026
Last Modified
June 26, 2026
First Seen
June 26, 2026

Related Vulnerabilities