CVE-2026-40171: Jupyter Notebook stored XSS enables

CISO Take

A stored Cross-Site Scripting vulnerability in Jupyter Notebook and JupyterLab allows an attacker to steal authentication tokens when a user opens a malicious notebook file and performs a single click on a UI element crafted to look indistinguishable from legitimate controls — no technical sophistication required from the victim. With 1,862 downstream dependents and EPSS placing this in the top 72% of likely-to-be-exploited vulnerabilities, the blast radius across AI/ML development environments is substantial, particularly given how freely notebooks are shared between data scientists, researchers, and CI pipelines. Exploitation grants full account takeover via the Jupyter REST API — read and modify all project files, inject code into running ML kernels, spawn terminal shells — making this an effective pivot point into training pipelines, model artifacts, and embedded credentials. Upgrade immediately to Jupyter Notebook 7.5.6 or JupyterLab 4.5.7; if patching is blocked, disable the help extension via `jupyter labextension disable @jupyter-notebook/help-extension` as an interim workaround.

Sources: GitHub Advisory EPSS OpenSSF ATLAS NVD

What is the risk?

HIGH. Jupyter is the most widely deployed ML experimentation platform, and stored XSS enabling auth token theft with subsequent REST API abuse is functionally equivalent to remote code execution in this context. The attack requires only that a user open a crafted notebook and click once — a routine action in collaborative data science workflows. No public exploit is confirmed yet, but the technique requires no special privileges or complex preconditions and was discovered by the NVIDIA AI Red Team, indicating active research interest. Organizations running JupyterHub in multi-user configurations face compounded risk as a single compromised token can pivot across shared ML infrastructure. An OpenSSF score of 4.8/10 and 14 prior CVEs in the same package signal a pattern of insufficient security hygiene in the dependency.

How does the attack unfold?

Notebook Weaponization

Attacker crafts a Jupyter notebook embedding a stored XSS payload in help extension content or markdown, visually disguised as a legitimate UI button or link.

AML.T0049

User Execution

Victim data scientist opens the shared notebook and performs a single click on the malicious element, triggering the XSS payload execution in their browser.

AML.T0011

Token Exfiltration

XSS payload silently captures the victim's Jupyter authentication token and transmits it to an attacker-controlled endpoint without any visible indication to the user.

AML.T0106

Full Environment Compromise

Attacker uses stolen token against the Jupyter REST API to read and modify all project files, execute arbitrary code in running ML kernels, and create persistent terminal shell sessions on the host.

AML.T0091.000

Notebook Weaponization

Attacker crafts a Jupyter notebook embedding a stored XSS payload in help extension content or markdown, visually disguised as a legitimate UI button or link.

AML.T0049

User Execution

Victim data scientist opens the shared notebook and performs a single click on the malicious element, triggering the XSS payload execution in their browser.

AML.T0011

Token Exfiltration

XSS payload silently captures the victim's Jupyter authentication token and transmits it to an attacker-controlled endpoint without any visible indication to the user.

AML.T0106

Full Environment Compromise

Attacker uses stolen token against the Jupyter REST API to read and modify all project files, execute arbitrary code in running ML kernels, and create persistent terminal shell sessions on the host.

AML.T0091.000

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Jupyter Notebook	npm	>= 7.0.0, <= 7.5.5	`7.5.6`
13.2K OpenSSF 5.8 3.0K dependents Pushed 5d ago 60% patched ~340d to patch Full package profile →
Jupyter	npm	<= 4.5.6	`4.5.7`
13.2K OpenSSF 5.8 1.9K dependents Pushed 5d ago 79% patched ~9d to patch Full package profile →
Jupyter	pip	<= 4.5.6	`4.5.7`
13.2K OpenSSF 5.8 1.9K dependents Pushed 5d ago 79% patched ~9d to patch Full package profile →
Jupyter Notebook	pip	>= 7.0.0, <= 7.5.5	`7.5.6`
13.2K OpenSSF 5.8 3.0K dependents Pushed 5d ago 60% patched ~340d to patch Full package profile →

How severe is it?

CVSS 3.1

N/A

EPSS

0.5%

chance of exploitation in 30 days

Higher than 37% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What should I do?

6 steps

Patch immediately: upgrade to notebook>=7.5.6 or jupyterlab>=4.5.7. Verify with pip show notebook jupyterlab.
Workaround if patching is blocked: jupyter labextension disable @jupyter-notebook/help-extension && jupyter labextension disable @jupyterlab/help-extension.
Harden in patched versions: set allowCommandLinker: false in overrides.json to disable the command linker globally.
Audit notebook provenance: restrict execution of externally-sourced notebooks until patched; implement notebook signing or content scanning in CI pipelines.
Review Jupyter access logs for anomalous REST API calls (especially file reads, kernel executions, and terminal creation) from tokens operating outside normal user sessions.
For JupyterHub deployments, validate server-side token scoping and expiration policies to limit lateral movement from a compromised token.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable No

Technical Impact total

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Auth Bypass Code Execution Data Extraction Framework Training Data AML.T0011 - User Execution AML.T0025 - Exfiltration via Cyber Means AML.T0037 - Data from Local System AML.T0049 - Exploit Public-Facing Application AML.T0072 - Reverse Shell AML.T0091.000 - Application Access Token AML.T0106 - Exploitation for Credential Access

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.6 - AI system security

NIST AI RMF

MANAGE-4.1 - Risk treatment and residual risk monitoring

OWASP LLM Top 10

LLM05:2025 - Improper Output Handling

Frequently Asked Questions

What is CVE-2026-40171?

A stored Cross-Site Scripting vulnerability in Jupyter Notebook and JupyterLab allows an attacker to steal authentication tokens when a user opens a malicious notebook file and performs a single click on a UI element crafted to look indistinguishable from legitimate controls — no technical sophistication required from the victim. With 1,862 downstream dependents and EPSS placing this in the top 72% of likely-to-be-exploited vulnerabilities, the blast radius across AI/ML development environments is substantial, particularly given how freely notebooks are shared between data scientists, researchers, and CI pipelines. Exploitation grants full account takeover via the Jupyter REST API — read and modify all project files, inject code into running ML kernels, spawn terminal shells — making this an effective pivot point into training pipelines, model artifacts, and embedded credentials. Upgrade immediately to Jupyter Notebook 7.5.6 or JupyterLab 4.5.7; if patching is blocked, disable the help extension via `jupyter labextension disable @jupyter-notebook/help-extension` as an interim workaround.

Is CVE-2026-40171 actively exploited?

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

How to fix CVE-2026-40171?

1. Patch immediately: upgrade to notebook>=7.5.6 or jupyterlab>=4.5.7. Verify with `pip show notebook jupyterlab`. 2. Workaround if patching is blocked: `jupyter labextension disable @jupyter-notebook/help-extension && jupyter labextension disable @jupyterlab/help-extension`. 3. Harden in patched versions: set `allowCommandLinker: false` in overrides.json to disable the command linker globally. 4. Audit notebook provenance: restrict execution of externally-sourced notebooks until patched; implement notebook signing or content scanning in CI pipelines. 5. Review Jupyter access logs for anomalous REST API calls (especially file reads, kernel executions, and terminal creation) from tokens operating outside normal user sessions. 6. For JupyterHub deployments, validate server-side token scoping and expiration policies to limit lateral movement from a compromised token.

What systems are affected by CVE-2026-40171?

This vulnerability affects the following AI/ML architecture patterns: ML experimentation environments, Training pipelines, JupyterHub multi-user deployments, Managed ML platforms (SageMaker Studio, Vertex AI Workbench, Azure ML), Data science collaborative workflows.

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

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

ML experimentation environmentsTraining pipelinesJupyterHub multi-user deploymentsManaged ML platforms (SageMaker Studio, Vertex AI Workbench, Azure ML)Data science collaborative workflows

MITRE ATLAS Techniques

AML.T0011 User Execution

AML.T0025 Exfiltration via Cyber Means

AML.T0037 Data from Local System

AML.T0049 Exploit Public-Facing Application

AML.T0072 Reverse Shell

AML.T0091.000 Application Access Token

AML.T0106 Exploitation for Credential Access

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.2.6

NIST AI RMF: MANAGE-4.1

OWASP LLM Top 10: LLM05:2025

What are the technical details?

Original Advisory

### Impact A stored Cross-Site Scripting (XSS) vulnerability in Jupyter Notebook allows attackers to steal authentication tokens from users who open malicious notebook files and interact with elements that the attacker can make look indistinguishable from legitimate controls (single click interaction). The vulnerability enables complete account takeover through the Jupyter REST API, allowing the attacker to: 1. Read all files 2. Modify/create files 3. Access running kernels and execute arbitrary code 4. Create terminals for shell access ### Patches Jupyter Notebook 7.5.6 and JupyterLab 4.5.7 include patches for this vulnerability. ### Workarounds The help extension can be disabled via CLI: ``` jupyter labextension disable @jupyter-notebook/help-extension jupyter labextension disable @jupyterlab/help-extension ``` ### Hardening The patched versions include a toggle to disable the command linker functionality altogether, for example via `overrides.json`: ```json { "@jupyterlab/apputils-extension:sanitizer": { "allowCommandLinker": false } } ``` ### Resources - https://jupyterlab.readthedocs.io/en/latest/user/commands.html#commands-in-markdown-output-and-files ### Acknowledgments Reported by Daniel Teixeira - NVIDIA AI Red Team

Exploitation Scenario

An adversary targeting an ML team embeds a stored XSS payload in a notebook's help extension content or a markdown cell, styling it to appear as a legitimate UI control — a 'Run All' button, a help link, or a dataset preview widget. The attacker shares the weaponized notebook via a plausible vector: a public GitHub repository, a Slack attachment in a data science channel, or as part of a shared dataset bundle. When a data scientist opens the file and clicks the disguised element — a single interaction — the XSS payload executes in their browser context, silently POSTs their Jupyter auth token to an attacker-controlled endpoint, and renders a benign decoy response. The attacker then calls the Jupyter REST API with the stolen token: enumerates and downloads all notebook files (harvesting embedded API keys and model artifacts), modifies training scripts to introduce silent label flipping or backdoor injection into upcoming model runs, and spawns a persistent terminal session for ongoing host-level access — all without triggering authentication events in application-level logs.

Weaknesses (CWE)

CWE-601 URL Redirection to Untrusted Site ('Open Redirect') Primary CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') Primary

CWE-601 — URL Redirection to Untrusted Site ('Open Redirect'): The web application accepts a user-controlled input that specifies a link to an external site, and uses that link in a redirect.

[Implementation] Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylis
[Architecture and Design] Use an intermediate disclaimer page that provides the user with a clear warning that they are leaving the current site. Implement a long timeout before the redirect occurs, or force the user to click on the link. Be careful to avoid XSS problems (CWE-79) when generating the disclaimer page.

Source: MITRE CWE corpus.