GHSA-whvh-wf3x-g77j

Summary

JupyterLab: Allowlist/blocklist check in `PyPIExtensionManager.install()` not enforced for direct callers (missing `await`)

Severity

low

CWE

CWE-284, CWE-636

Published

2026-07-22

Updated

2026-07-22

Advisory details

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/advisories/GHSA-whvh-wf3x-g77j
• 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

Related advisories

• GHSA-pppj-hq3g-57pj — high · PyPI/jupyterlab
• GHSA-gx64-gj6p-pc4c — high · PyPI/jupyterlab
• CVE-2026-42266 — high · PyPI/jupyterlab
• CVE-2026-42557 — high · PyPI/jupyterlab
• CVE-2026-40171 — high · PyPI/jupyterlab
• GHSA-89vp-jrxv-24w8 — medium · PyPI/jupyterlab
• GHSA-h5v5-8746-g7mm — medium · PyPI/jupyterlab
• GHSA-vmhf-c436-hxj4 — medium · PyPI/jupyterlab

Is your project exposed to this? Stateward checks every dependency on every pull request and flags it only if your code actually reaches it.

Summarize with AI

ChatGPTClaudePerplexity