Database/AI/ML frameworks & serving
JupyterLab: missing await skips extension allowlist check for direct PyPIExtensionManager callers
Impact
The is_install_allowed coroutine was never awaited, so the configured extension allowlist/blocklist was not enforced for code paths that call PyPIExtensionManager.install() directly. Where that applies, an operator-configured guard against installing arbitrary PyPI packages into the notebook environment silently does nothing, and package installation is code execution as the notebook user - on a GPU node that means a foothold in a pod holding the accelerator. The exposure is narrow and worth checking before you act: stock JupyterLab, including the HTTP API and the Extension Manager UI, is not affected because they perform their own correctly awaited check. It only bites deployments where a custom extension or downstream integration calls install() with a package name derived from untrusted input, an allowlist or blocklist is configured, the PyPI extension manager is enabled, and kernels and terminals are disabled or remote - that is, exactly the hardened setups that were relying on the allowlist as the boundary.
Who can reach it
A user who can influence the package name reaching a custom integration's install() call, on a deployment matching all four conditions above. Authentication is whatever that integration requires.
What to do
Upgrade to JupyterLab 4.6.2 or 4.5.10 and restart the notebook servers - a service restart, and on JupyterHub it can be rolled per-user as sessions cycle. Affected versions are 4.6.0 through 4.6.1 and 4.5.9 and earlier. If you run stock JupyterLab with no custom integration calling PyPIExtensionManager directly, this is a routine upgrade rather than an urgent one.
References
Related entries
- Headroom LLM proxy: client-chosen upstream base URL enables SSRF and leaks the Authorization headerCVE-2026-77775 · Headroom LLM proxy (x-headroom-base-url upstream selection)High
- JupyterLab: XSS via untrusted notebook contentCVE-2024-43805 · JupyterLabHigh
- ONNX: Directory traversal via `external_data` field in the tensor protoCVE-2022-25882 · ONNXHigh
- Dagster (webserver): Directory traversalCVE-2023-51232 · Dagster (webserver)High
- Ray (log API): LFI — read any file on the head node, unauthenticatedCVE-2023-6021 · Ray (log API)High
- LiteLLM: Unauthenticated DoS via `ast.literal_eval` on user inputCVE-2024-10188 · LiteLLMHigh
This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.