CVE-2026-42266: Jupyter Extension allow-list bypass

Q: Is CVE-2026-42266 actively exploited?

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

Q: How to fix CVE-2026-42266?

1) Patch: Upgrade jupyterlab to v4.5.7 immediately; if running Notebook v7+, verify the jupyterlab dependency is also updated to 4.5.7+. 2) Workaround if patching is delayed: Set extension manager to read-only mode via `--LabApp.extension_manager=readonly` CLI flag or `c.LabApp.extension_manager = 'readonly'` in traitlet config. 3) Do not rely on a PyPI proxy with allow-listed packages — this is explicitly stated as insufficient by the advisory. 4) Detection: Audit installed extensions across all user environments for packages not in your approved list; review extension installation logs for anomalous activity. 5) JupyterHub admins should consider temporarily disabling the PyPI Extension Manager cluster-wide until patching is complete.

Q: What systems are affected by CVE-2026-42266?

This vulnerability affects the following AI/ML architecture patterns: Multi-tenant JupyterHub environments, Shared ML training infrastructure, Data science workbenches, Collaborative AI research platforms.

Q: What is the CVSS score for CVE-2026-42266?

CVE-2026-42266 has a CVSS v3.1 base score of 8.8 (HIGH). The EPSS exploitation probability is 0.49%.

CISO Take

JupyterLab's PyPI Extension Manager fails to enforce the configured extension allow-list, allowing any authenticated user to install arbitrary packages from outside the approved list — a direct bypass of the primary control administrators rely on to restrict software in shared environments. This is most dangerous in multi-tenant JupyterHub deployments common across universities, enterprise ML platforms, and collaborative research environments, where the allow-list is often the only layer preventing users from installing unapproved code. With a CVSS of 8.8, network-accessible, low complexity, and 1,862 downstream dependents across the ecosystem, the blast radius for shared ML infrastructure is substantial. Upgrade to JupyterLab 4.5.7 immediately — Notebook v7+ users must also update the underlying jupyterlab dependency — or switch the extension manager to read-only mode via `--LabApp.extension_manager=readonly`; note that a PyPI proxy allow-list alone is explicitly insufficient as a workaround.

Sources: NVD GitHub Advisory ATLAS OpenSSF

What is the risk?

High risk for any multi-tenant deployment. CVSS 8.8 with network vector, low complexity, and low privileges required creates a broadly exploitable attack surface requiring only a valid account. The vulnerability undermines a deliberate security control rather than exploiting a misconfiguration, meaning organizations that believed they had isolation through allow-listing are directly exposed. Single-user deployments with no sensitive data or network access are lower risk. The OpenSSF Scorecard of 4.8/10 and 9 prior CVEs in the same package suggest ongoing security debt in the project.

How does the attack unfold?

Initial Access

Authenticated attacker with a valid low-privilege account in a shared JupyterHub or multi-tenant JupyterLab environment initiates the attack from the web UI.

AML.T0012

Allow-list Bypass

Attacker crafts an extension install request that circumvents the PyPI Extension Manager's allow-list enforcement, exploiting client-side security control failure (CWE-602/CWE-88).

AML.T0049

Malicious Package Install

A malicious or attacker-controlled package from an unapproved PyPI source is installed into the single-user server environment, achieving arbitrary code execution.

AML.T0011.001

Impact

Attacker achieves privilege escalation enabling data exfiltration of training data and model artifacts, lateral movement to internal network resources, or persistent server compromise via backdoor.

AML.T0010.001

Initial Access

Authenticated attacker with a valid low-privilege account in a shared JupyterHub or multi-tenant JupyterLab environment initiates the attack from the web UI.

AML.T0012

Allow-list Bypass

Attacker crafts an extension install request that circumvents the PyPI Extension Manager's allow-list enforcement, exploiting client-side security control failure (CWE-602/CWE-88).

AML.T0049

Malicious Package Install

A malicious or attacker-controlled package from an unapproved PyPI source is installed into the single-user server environment, achieving arbitrary code execution.

AML.T0011.001

Impact

Attacker achieves privilege escalation enabling data exfiltration of training data and model artifacts, lateral movement to internal network resources, or persistent server compromise via backdoor.

AML.T0010.001

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Jupyter	pip	—	No patch
13.2K OpenSSF 5.8 1.9K dependents Pushed 7d ago 79% patched ~9d to patch Full package profile →
Jupyter	pip	>= 4.0.0, <= 4.5.6	`4.5.7`
13.2K OpenSSF 5.8 1.9K dependents Pushed 7d ago 79% patched ~9d to patch Full package profile →
Jupyter Notebook	pip	—	No patch
13.2K OpenSSF 5.8 3.0K dependents Pushed 7d ago 58% patched ~371d to patch Full package profile →

How severe is it?

CVSS 3.1

8.8 / 10

EPSS

0.5%

chance of exploitation in 30 days

Higher than 38% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Trivial

What is the attack surface?

AV Network

AC Low

PR Low

UI None

S Unchanged

C High

I High

A High

What should I do?

1 step

1) Patch: Upgrade jupyterlab to v4.5.7 immediately; if running Notebook v7+, verify the jupyterlab dependency is also updated to 4.5.7+. 2) Workaround if patching is delayed: Set extension manager to read-only mode via --LabApp.extension_manager=readonly CLI flag or c.LabApp.extension_manager = 'readonly' in traitlet config. 3) Do not rely on a PyPI proxy with allow-listed packages — this is explicitly stated as insufficient by the advisory. 4) Detection: Audit installed extensions across all user environments for packages not in your approved list; review extension installation logs for anomalous activity. 5) JupyterHub admins should consider temporarily disabling the PyPI Extension Manager cluster-wide until patching is complete.

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?

Supply Chain Auth Bypass Code Execution Framework Plugin AML.T0010.001 - AI Software AML.T0011.001 - Malicious Package AML.T0012 - Valid Accounts AML.T0049 - Exploit Public-Facing Application

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity Article 9 - Risk management system

ISO 42001

A.10.1 - AI supply chain A.6.2 - Risk management for AI systems

NIST AI RMF

GOVERN 1.1 - Policies, processes, and procedures are in place

OWASP LLM Top 10

LLM05 - Supply Chain Vulnerabilities LLM07 - Insecure Plugin Design

Frequently Asked Questions

What is CVE-2026-42266?

JupyterLab's PyPI Extension Manager fails to enforce the configured extension allow-list, allowing any authenticated user to install arbitrary packages from outside the approved list — a direct bypass of the primary control administrators rely on to restrict software in shared environments. This is most dangerous in multi-tenant JupyterHub deployments common across universities, enterprise ML platforms, and collaborative research environments, where the allow-list is often the only layer preventing users from installing unapproved code. With a CVSS of 8.8, network-accessible, low complexity, and 1,862 downstream dependents across the ecosystem, the blast radius for shared ML infrastructure is substantial. Upgrade to JupyterLab 4.5.7 immediately — Notebook v7+ users must also update the underlying jupyterlab dependency — or switch the extension manager to read-only mode via `--LabApp.extension_manager=readonly`; note that a PyPI proxy allow-list alone is explicitly insufficient as a workaround.

Is CVE-2026-42266 actively exploited?

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

How to fix CVE-2026-42266?

1) Patch: Upgrade jupyterlab to v4.5.7 immediately; if running Notebook v7+, verify the jupyterlab dependency is also updated to 4.5.7+. 2) Workaround if patching is delayed: Set extension manager to read-only mode via `--LabApp.extension_manager=readonly` CLI flag or `c.LabApp.extension_manager = 'readonly'` in traitlet config. 3) Do not rely on a PyPI proxy with allow-listed packages — this is explicitly stated as insufficient by the advisory. 4) Detection: Audit installed extensions across all user environments for packages not in your approved list; review extension installation logs for anomalous activity. 5) JupyterHub admins should consider temporarily disabling the PyPI Extension Manager cluster-wide until patching is complete.

What systems are affected by CVE-2026-42266?

This vulnerability affects the following AI/ML architecture patterns: Multi-tenant JupyterHub environments, Shared ML training infrastructure, Data science workbenches, Collaborative AI research platforms.

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

CVE-2026-42266 has a CVSS v3.1 base score of 8.8 (HIGH). The EPSS exploitation probability is 0.49%.

What is the AI security impact?

Affected AI Architectures

Multi-tenant JupyterHub environmentsShared ML training infrastructureData science workbenchesCollaborative AI research platforms

MITRE ATLAS Techniques

AML.T0010.001 AI Software

AML.T0011.001 Malicious Package

AML.T0012 Valid Accounts

AML.T0049 Exploit Public-Facing Application

Compliance Controls Affected

EU AI Act: Article 15, Article 9

ISO 42001: A.10.1, A.6.2

NIST AI RMF: GOVERN 1.1

OWASP LLM Top 10: LLM05, LLM07

What are the technical details?

Original Advisory

The allow-list of extensions that can be installed from PyPI Extension Manager (`allowed_extensions_uris`) is not correctly enforced by JupyterLab prior to 4.5.X. The PyPI Extension Manager was not contained to packages listed on the default PyPI index. This has security implications for deployments that: - have allow-listed specific extensions with aim to prevent users from installing packages - have the kernel and terminals disabled or delegated to remote hosts (thus no access to install packages in the single-user server environment) - have multi-tenant deployments that is not configured for untrusted users (as per documented on JupyterHub https://jupyterhub.readthedocs.io/en/5.2.1/explanation/websecurity.html) - have the (default) PyPI Extension Manger enabled ### Impact An authenticated attacker - such as a student in a shared JupyterHub environment or a user in a multi-tenant JupyterLab deployment - can escalate their privileges. This might allow for data exfiltration, lateral movement within the network, and persistent compromise of the server infrastructure. ### Patches JupyterLab [`v4.5.7`](https://github.com/jupyterlab/jupyterlab/releases/tag/v4.5.7) contains the patch. Users of applications that depend on JupyterLab, such as Notebook v7+, should update `jupyterlab` package too. ### Workarounds Switch to read-only extension manager by adding the following command line option: ```bash --LabApp.extension_manager=readonly ``` or the following traitlet: ```python c.LabApp.extension_manager = 'readonly' ``` You can confirm that the read-only manager is in use from GUI: <img width="293" height="293" alt="image" src="https://github.com/user-attachments/assets/8016c809-633e-4ed0-a5bc-6bc4793caa0f" /> Note: configuration of a PyPI proxy with allow-listed packages is not sufficient to protect from this vulnerability. ### Resources - allow-list https://jupyterlab.readthedocs.io/en/stable/user/extensions.html#listing-configuration - https://jupyterhub.readthedocs.io/en/5.2.1/explanation/websecurity.html - https://jupyterlab.readthedocs.io/en/latest/user/extensions.html#extension-manager-implementations

Exploitation Scenario

A student or low-privilege user in a shared university JupyterHub deployment with a valid account accesses the JupyterLab UI and attempts to install a package that is not on the administrator-configured allow-list. Because the allow-list enforcement is implemented client-side and not correctly enforced server-side (CWE-602, CWE-88), the request succeeds. The attacker installs a malicious PyPI package — potentially one they published themselves — which executes arbitrary code within the single-user server environment upon import. From this position, the attacker can read other users' notebooks if file permissions allow, exfiltrate training datasets or model weights stored on the server, establish a reverse shell for persistent access, or pivot to internal network resources reachable from the Jupyter server.

Weaknesses (CWE)

CWE-20 Improper Input Validation Primary CWE-602 Client-Side Enforcement of Server-Side Security Primary CWE-88 Improper Neutralization of Argument Delimiters in a Command ('Argument Injection') Primary

CWE-20 — Improper Input Validation: The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly.

[Architecture and Design] Consider using language-theoretic security (LangSec) techniques that characterize inputs using a formal language and build "recognizers" for that language. This effectively requires parsing to be a distinct layer that effectively enforces a boundary between raw input and internal data representations, instead of allowing parser code to be scattered throughout the program, where it could be subject to errors or inconsistencies that create weaknesses. [REF-1109] [REF-1110] [REF-1111]
[Architecture and Design] Use an input validation framework such as Struts or the OWASP ESAPI Validation API. Note that using a framework does not automatically address all input validation problems; be mindful of weaknesses that could arise from misusing the framework itself (CWE-1173).

Source: MITRE CWE corpus.