GHSA-37w4-hwhx-4rc4
HIGHGHSA-37w4-hwhx-4rc4 is a high-severity (CVSS 8.8) CWE-88 vulnerability in jupyterlab. O3 Security confirms whether GHSA-37w4-hwhx-4rc4 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
JupyterLab has an Extension Manager API/GUI Policy Discrepancy, allowing 3rd party (malicious) extensions install via POST request
Blast Radius
jupyterlabReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
The allow-list of extensions that can be installed from PyPI Extension Manager (allowed_extensions_uris) is not correctly enforced by JupyterLab prior to 4.5.7. The PyPI Extension Manager was not contained to packages listed on the default PyPI index.
This has security implications for deployments that:
- have allow-listed specific extensions with aim to prevent users from installing packages
- have the kernel and terminals disabled or delegated to remote hosts (thus no access to install packages in the single-user server environment)
- have multi-tenant deployments that is not configured for untrusted users (as per documented on JupyterHub https://jupyterhub.readthedocs.io/en/5.2.1/explanation/websecurity.html)
- have the (default) PyPI Extension Manager enabled
Impact
An authenticated attacker - such as a student in a shared JupyterHub environment or a user in a multi-tenant JupyterLab deployment - can escalate their privileges. This might allow for data exfiltration, lateral movement within the network, and persistent compromise of the server infrastructure.
Patches
JupyterLab v4.5.7 contains the patch.
Users of applications that depend on JupyterLab, such as Notebook v7+, should update jupyterlab package too.
Workarounds
Switch to read-only extension manager by adding the following command line option:
--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:
<img width="293" height="293" alt="image" src="https://github.com/user-attachments/assets/8016c809-633e-4ed0-a5bc-6bc4793caa0f" />Note: configuration of a PyPI proxy with allow-listed packages is not sufficient to protect from this vulnerability.
References
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | jupyterlab | ≥ 4.0.0&&< 4.5.7 | 4.5.7 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for jupyterlab. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update jupyterlab to 4.5.7 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-37w4-hwhx-4rc4 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-37w4-hwhx-4rc4 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-37w4-hwhx-4rc4. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-37w4-hwhx-4rc4 in your dependencies?
O3 detects GHSA-37w4-hwhx-4rc4 across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.