Summary
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)
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:
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.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
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.
Frequently Asked Questions
- What is GHSA-WHVH-WF3X-G77J? GHSA-WHVH-WF3X-G77J is a low-severity security vulnerability in jupyterlab (pip), affecting versions >= 4.6.0, <= 4.6.1. It is fixed in 4.6.2, 4.5.10.
- Which versions of jupyterlab are affected by GHSA-WHVH-WF3X-G77J? jupyterlab (pip) versions >= 4.6.0, <= 4.6.1 is affected.
- Is there a fix for GHSA-WHVH-WF3X-G77J? Yes. GHSA-WHVH-WF3X-G77J is fixed in 4.6.2, 4.5.10. Upgrade to this version or later.
- Is GHSA-WHVH-WF3X-G77J exploitable, and should I be worried? Whether GHSA-WHVH-WF3X-G77J is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether GHSA-WHVH-WF3X-G77J is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix GHSA-WHVH-WF3X-G77J?
- Upgrade
jupyterlabto 4.6.2 or later - Upgrade
jupyterlabto 4.5.10 or later
- Upgrade