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
PyPIExtensionManager and calls install() 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 calling install());
- 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:

### 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/releases/tag/v4.5.10
- https://github.com/jupyterlab/jupyterlab/releases/tag/v4.6.2
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 aRuntimeWarning: coroutine 'is_install_allowed' was never awaited.This has security implications only for deployments that combine all of the following:
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());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.2andv4.5.10contain the patch.Users of applications that depend on JupyterLab, such as Notebook v7+, should update
jupyterlabpackage 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:
or the following traitlet:
You can confirm that the read-only manager is in use from GUI:

### 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/releases/tag/v4.5.10 - https://github.com/jupyterlab/jupyterlab/releases/tag/v4.6.2