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.7. 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 Manager 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. ### References - 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
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.7. 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 Manager 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. ### References - 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
Update jupyterlab to 4.5.7 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanJupyterLab has an Extension Manager API/GUI Policy Discrepancy, allowing 3rd party (malicious) extensions install via POST request affects jupyterlab (pip). Severity is high. 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.7. 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 Manager 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. ### References - 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
AI coding agents often install or upgrade packages automatically in pip. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| jupyterlabpip | >=4.0.0,<=4.5.6 | 4.5.7 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate jupyterlab to 4.5.7 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanJupyterLab has an Extension Manager API/GUI Policy Discrepancy, allowing 3rd party (malicious) extensions install via POST request affects jupyterlab (pip). Severity is high. 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.7. 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 Manager 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. ### References - 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
AI coding agents often install or upgrade packages automatically in pip. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| jupyterlabpip | >=4.0.0,<=4.5.6 | 4.5.7 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard