JupyterLab: extension allow-list not enforced, letting a notebook user install arbitrary PyPI packages

Impact

An operator who locked the extension manager down to an approved internal index via allowed_extensions_uris did not actually get that restriction: JupyterLab did not confine the PyPI Extension Manager to the configured list, so any package reachable on the default PyPI index could be installed. Installing a Python package runs its build and import code, so this is code execution inside the notebook process - which on a GPU fleet is a pod or VM holding a leased accelerator, with the tenant's data, mounted shared storage and any credentials injected into that environment. The record scores it 8.8 with low privileges required, meaning an authenticated notebook user, not an anonymous one. Where JupyterLab ships as part of Red Hat OpenShift AI, the same weakness reaches whatever workbench images that cluster hands to data scientists.

Who can reach it

A user who can already authenticate to a JupyterLab server (4.0.0 through 4.5.6) and reach the extension manager UI. Requires authentication and network reach to PyPI or the configured index; not exploitable by an unauthenticated outsider.

What to do

Upgrade JupyterLab to 4.5.7 and restart each notebook server so the new code is loaded - on a shared cluster this means rebuilding or repulling the workbench image and cycling running notebook pods, which interrupts in-flight sessions but does not require draining the GPU node. Red Hat OpenShift AI and Migration Toolkit for Applications users should apply RHSA-2026:43038. If the upgrade cannot be scheduled immediately, disable the PyPI Extension Manager rather than relying on allowed_extensions_uris, since the allow-list is what fails here.

References

Related entries

• LiteLLM proxy: Two endpoints allow privilege escalation / unauthorized actionCVE-2026-42271 · LiteLLM proxyHigh
• BentoML (`bentofile.yaml`): Malicious build manifestCVE-2026-44346 · BentoML (`bentofile.yaml`)High
• ChromaDB (SimpleRBAC): Authorization provider evaluates permissions incorrectlyCVE-2026-45831 · ChromaDB (SimpleRBAC)High
• ChromaDB (V1 endpoints): Tenant/database passed as `None` to the authz layerCVE-2026-45832 · ChromaDB (V1 endpoints)High
• ChromaDB: Authenticated code injectionCVE-2026-45833 · ChromaDBHigh
• LiteLLM (key generation): internal_user can mint keys with routes their role forbidsCVE-2026-47101 · LiteLLM (key generation)High