Skip to main content

JupyterLab CVE-2026-42266

HIGH
Improper Input Validation (CWE-20)
2026-05-05 https://github.com/jupyterlab/jupyterlab GHSA-37w4-hwhx-4rc4
8.8
CVSS 3.1
Share

CVSS VectorNVD

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Attack Vector
Network
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

2
Source Code Evidence Fetched
May 05, 2026 - 21:31 vuln.today
Analysis Generated
May 05, 2026 - 21:31 vuln.today

Blast Radius

ecosystem impact
† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth
  • 1 pypi packages depend on jupyterlab (1 direct, 0 indirect)

Ecosystem-wide dependent count for version 4.0.0.

DescriptionNVD

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 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

AnalysisAI

Privilege escalation in JupyterLab 4.0.0 through 4.5.6 allows authenticated users to bypass extension allow-list controls and install arbitrary PyPI packages, enabling potential data exfiltration and lateral movement in multi-tenant deployments. The PyPI Extension Manager failed to enforce the allowed_extensions_uris configuration, permitting installation of packages outside the approved list. …

Sign in for full analysis, threat intelligence, and remediation guidance.

RemediationAI

Within 24 hours: Identify all JupyterLab instances running versions 4.0.0-4.5.6 using inventory/asset management tools and determine exposure scope (single-tenant vs. multi-tenant deployments). …

Sign in for detailed remediation steps.

Vendor StatusVendor

Share

CVE-2026-42266 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy