JupyterLab: Allowlist/blocklist check in `PyPIExtensionManager.install()` not enforced for direct callers (missing `await`)
The extension allowlist/blocklist check inside PyPIExtensionManager.install() was not enforced due to a missing await. For purposes of JupyterLab this was a secondary defense-in-depth check: install() was intended to enforce the allowlist/blocklist itself for any future uses and users calling this method directly (in addition to the separate check handling requests arriving through the HTTP API). The only runtime symptom was a RuntimeWarning: coroutine 'is_install_allowed' was never awaited.
This has security implications only for deployments that combine all of the following:
- a custom extension or downstream integration that imports
PyPIExtensionManagerand callsinstall()directly with a package name influenced by untrusted user input (the stock JupyterLab HTTP handler is not affected - it performs its own awaited allowlist check before callinginstall()); - an allowlist/blocklist configured with the intent of restricting which packages users can install;
- the (default) PyPI Extension Manager enabled; and
- kernels and terminals disabled or delegated to remote hosts, so that the custom extension's
install()call is the only available package-install vector (otherwise a user with kernel access can install packages directly regardless of this check)
Impact
Low. No exposure for stock JupyterLab: the HTTP API and Extension Manager UI enforce the listing through a separate, correctly awaited check. The gap affected only custom extensions or downstream integrations that called the public install() method directly and relied on it to self-enforce.
Patches
JupyterLab v4.6.2 and v4.5.10 contain the patch.
Users of applications that depend on JupyterLab, such as Notebook v7+, should update jupyterlab package too.
Workarounds
No action is required for deployments that only expose extension management through the JupyterLab HTTP API / Extension Manager UI, as that path was already enforcing the listing via the handler's own check. Deployments wanting to disable programmatic extension installation entirely can switch to the read-only extension manager:
--LabApp.extension_manager=readonly
or the following traitlet:
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" />Affected software
Click a technology to see all vulnerabilities affecting it.
| Platform | Package | Vulnerable versions | Fixed in |
|---|---|---|---|
| Python (PyPI) | jupyterlab | >= 4.6.0, < 4.6.2, < 4.5.10 | 4.6.2, 4.5.10 |
References
- https://github.com/jupyterlab/jupyterlab/security/advisories/GHSA-whvh-wf3x-g77j
- https://github.com/jupyterlab/jupyterlab/pull/19184
- https://github.com/jupyterlab/jupyterlab/pull/19185
- https://github.com/jupyterlab/jupyterlab/pull/19186
- https://github.com/jupyterlab/jupyterlab/commit/be9303f5bcd5308eaeae953c5a3c903046682c2c
- https://github.com/jupyterlab/jupyterlab/commit/f1beab4a2027af4719d6edc07d52d6cf5a39a432
- https://github.com/jupyterlab/jupyterlab
- https://github.com/jupyterlab/jupyterlab/releases/tag/v4.5.10
- https://github.com/jupyterlab/jupyterlab/releases/tag/v4.6.2
- CVSS vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:N- Weakness (CWE)
CWE-284, CWE-636- Platform
- Python (PyPI)
- Package
jupyterlab- Disclosed
- 22.07.2026
- Updated
- 11.10.2026 15:18
Sources and licenses
OSV / GitHub Advisory Database - GHSA-whvh-wf3x-g77j - CC BY 4.0
Vulnerability history: jupyterlab
All published vulnerabilities of this package (Python (PyPI)), newest first. Shows whether this is a one-off slip or a package that needs watching.
- Total entries
- 19
- First → latest
- 08.2021 10.2026
- Without a fix
- 0
- Exploited in attacks
- 0
Severity breakdown
- Critical 1
- High 8
- Medium 8
- Low 2
Disclosures per year
- 2021: 1
- 2022: 0
- 2023: 0
- 2024: 4
- 2025: 1
- 2026: 13
-
JupyterLab: Allowlist/blocklist check in `PyPIExtensionManager.install()` not enforced for direct callers (missing `await`) this entry
Know which vulnerabilities affect your application
With the DockRay integration and software inventory enabled, DockRay checks reported component versions against known vulnerabilities and notifies you about confirmed matches. Coverage depends on the supported technology and available advisory data.