GHSA-h5v5-8746-g7mm
JupyterLab PluginManager lock-rule enforcement bypass
Blast Radius
jupyterlab🐍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
JupyterLab's plugin manager exposes administrator controls intended to prevent users from enabling or disabling selected plugins. Two server-side enforcement gaps let an authenticated user bypass those controls with direct requests to /lab/api/plugins.
Impact
Users could workaround the plugin manager lock rules via direct API access for either:
- child plugins of extensions covering multiple plugins
- when "lock all" was issued by the administrator
The integrity of data can be impacted, and any hardening or restrictions on permitted user actions (e.g. download/upload limits) within the single-user server can be circumvented if those were implemented with plugins that were locked using the faulty mechanisms.
Patches
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.
Workarounds
Manually lock all plugins that should be locked. The core plugin identifiers can be found in the documentation and identifiers for all installed extensions are listed in the Plugin Manager.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | jupyterlab | ≥ 4.6.0&&< 4.6.2 | 4.6.2 |
| 🐍PyPI | jupyterlab | ≥ 4.1.0&&< 4.5.10 | 4.5.10 |
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.6.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-h5v5-8746-g7mm 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-h5v5-8746-g7mm 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-h5v5-8746-g7mm. 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-h5v5-8746-g7mm in your dependencies?
O3 detects GHSA-h5v5-8746-g7mm across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.