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

CVE-2026-42266 has a CVSS 3.1 base score of 8.8 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. EPSS exploitation probability: 0.1%.

Which versions of JupyterLab are affected by CVE-2026-42266?

JupyterLab versions 4.0.0 through 4.5.6 contain a privilege escalation vulnerability allowing authenticated users to install unauthorized packages, bypassing security controls designed to restrict…. A patch is available.

How to fix or mitigate CVE-2026-42266?

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). Within 7 days: Upgrade all affected JupyterLab instances to version 4.5.7 or later; test in staging environment first. Within 30 days: Conduct audit of extension installation logs (if available) and validate that `allowed_extensions_uris` configuration is enforced post-upgrade; review access controls for shared JupyterHub environments to confirm kernel/terminal restrictions remain in place.

JupyterLab CVE-2026-42266

HIGH

Improper Input Validation (CWE-20)

2026-05-05 https://github.com/jupyterlab/jupyterlab

GHSA-37w4-hwhx-4rc4

Python Privilege Escalation

8.8

CVSS 3.1 · Vendor: https://github.com/jupyterlab/jupyterlab

Severity by source

Vendor (https://github.com/jupyterlab/jupyterlab) PRIMARY

8.8 HIGH

AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Red Hat

8.8 HIGH

qualitative

Primary rating from Vendor (https://github.com/jupyterlab/jupyterlab).

CVSS VectorVendor: https://github.com/jupyterlab/jupyterlab

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

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.

DescriptionCVE.org

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:

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. This vulnerability is particularly critical in shared educational environments (JupyterHub) and multi-tenant deployments where kernel/terminal access is restricted. Vendor-released patch available in JupyterLab v4.5.7. No public exploit identified at time of analysis, though exploitation requires only authenticated access with low complexity (CVSS AC:L).

Technical ContextAI

JupyterLab is a web-based interactive development environment for Jupyter notebooks, code, and data. The PyPI Extension Manager is a built-in GUI feature that allows users to discover and install Python extensions from the Python Package Index (PyPI). This vulnerability (CWE-20: Improper Input Validation) stems from insufficient enforcement of the allowed_extensions_uris configuration parameter, which administrators use to restrict installable extensions to a specific allow-list. The flaw exists in the server-side validation logic that processes extension installation requests, failing to properly validate that requested packages match the configured URI allow-list. This creates a policy discrepancy between the intended administrative controls and actual enforcement, effectively bypassing the security boundary meant to separate user capabilities from package installation privileges. Affected package identified via CPE: pkg:pip/jupyterlab versions 4.0.0 through 4.5.6.

RemediationAI

Upgrade JupyterLab to version 4.5.7 or later, which contains the validated patch for this vulnerability (release details at https://github.com/jupyterlab/jupyterlab/releases/tag/v4.5.7). For deployments using applications that bundle JupyterLab such as Jupyter Notebook v7+, ensure the underlying jupyterlab package dependency is also updated to 4.5.7 or later. If immediate patching is not feasible, implement the workaround by switching to read-only extension manager mode using either command-line option --LabApp.extension_manager=readonly or configuration traitlet c.LabApp.extension_manager = 'readonly' in your JupyterLab configuration file. Trade-off: this workaround completely disables extension installation capabilities for all users, including administrators, which may impact legitimate workflow requirements. Verify read-only mode is active through the GUI (settings icon should display lock indication). Note that configuring a PyPI proxy with allow-listed packages is explicitly NOT sufficient to mitigate this vulnerability due to the server-side validation bypass. For multi-tenant deployments, review and apply security hardening guidance from https://jupyterhub.readthedocs.io/en/5.2.1/explanation/websecurity.html.