Read the docs
TI-2026-67101 Aliases GHSA-whvh-wf3x-g77j

JupyterLab: Allowlist/blocklist check in `PyPIExtensionManager.install()` not enforced…

Priority LOW 38CWE-284Published · Updated

Key facts

Attack vector
—
Privileges required
—
User interaction
—
Attack complexity
—
Impact type
Security bypass
Confidentiality · integrity · availability
—
Fix status
Fixed

No CVSS vector from any source. Fix status from GitHub. Impact type from CWE-284.

Summary

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`](https://github.com/jupyterlab/jupyterlab/releases/tag/v4.6.2) and [`v4.5.10`](https://github.com/jupyterlab/jupyterlab/releases/tag/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: ```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" />

Why it matters now

Fix Fixed jupyterlab (PyPI): 4.6.2, 4.5.10

SSVC decision points

Not available: CISA has not published SSVC decision points for this record.

Affected products

VendorProductAffected versionsFixed inStatusSource
—jupyterlab (PyPI)4.6.0 to before 4.6.24.6.2Patch availableGHSA-whvh-wf3x-g77j
—jupyterlab (PyPI)before 4.5.104.5.10Patch availableGHSA-whvh-wf3x-g77j
  • jupyterlab (PyPI) Vendor— Affected 4.6.0 to before 4.6.2 Fixed in 4.6.2 Patch available GHSA-whvh-wf3x-g77j
  • jupyterlab (PyPI) Vendor— Affected before 4.5.10 Fixed in 4.5.10 Patch available GHSA-whvh-wf3x-g77j

Remediation

  • Fix · GHSA-whvh-wf3x-g77j jupyterlab (PyPI) Fixed in 4.6.2 Advisory →
  • Fix · GHSA-whvh-wf3x-g77j jupyterlab (PyPI) Fixed in 4.5.10 Advisory →

Timeline

  1. 2026-10-03 Threatist record created from GHSA-whvh-wf3x-g77j

References

Sources

This product uses the NVD API but is not endorsed or certified by the NVD. Sources and licences