JupyterLab's PyPI extension manager enforces blocked extensions via a custom string normalization that is weaker than PyPI's canonicalization. This allows an authenticated user to bypass blocklist restrictions by requesting package names that are equivalent under PyPI's normalization but differ in spelling (e.g., 'JupyterLab.Git' bypassing a block on 'jupyterlab-git'). This bypass occurs only in deployments that use a custom allow/block list, have the default PyPI Extension Manager enabled, and have kernels and terminals disabled or delegated remotely. The vulnerability enables installation of blocked packages, potentially allowing arbitrary code execution within the user's single-user server environment, impacting integrity and availability but not increasing read access beyond the user's own data. The vulnerability is patched in JupyterLab versions 4.6.2 and 4.5.10.

An authenticated user can install packages that operators intended to block, defeating allowlist/blocklist controls. This can lead to arbitrary code execution within the user's single-user server environment, impacting data integrity and circumventing user action restrictions. Availability impact on JupyterHub deployments is limited to resource exhaustion risks on the user's own server and potentially shared resources if limits are absent. No new read access to other users' data is granted.

Patches are available in JupyterLab versions 4.6.2 and 4.5.10. Users of dependent applications such as Notebook v7+ should also update the jupyterlab package. Deployments without custom allow/block lists require no action. To disable programmatic extension installation entirely, switch to the read-only extension manager by setting '--LabApp.extension_manager=readonly' or 'c.LabApp.extension_manager = "readonly"'. Verify the read-only manager is active via the GUI.