GHSA-pppj-hq3g-57pj
JupyterLab: Cross-site scripting (XSS) via crafted settings file (`overrides.json`)
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 4.5+ allows notebook settings to be shared and applied through an overrides.json file using the Import button in the Settings Editor.
Certain notebook display settings were not properly validated before being applied. As a result, a crafted settings file could contain hidden instructions that run as code inside JupyterLab when imported, instead of only changing a display preference.
Because importing a settings file appears harmless, a user could import a file shared by another party without realizing it could do more. On multi-tenant file systems without proper permission control, another user could plant a malicious overrides.json.
CVE assignment pending, GitHub CNA is experiencing severe backlog
Impact
When a malicious settings file is applied, the embedded code runs with the same access as the affected user. This could allow an attacker to read or modify that user's notebooks and files, and to run code on the user's behalf through the notebook server, including on any connected kernel.
User Interaction vs Privileges Required
Write access to a loaded settings location
If an attacker can write to a directory JupyterLab loads settings from (e.g. on shared or multi-tenant file system), they could place a crafted overrides.json that is applied to another user automatically at startup. This requires high privilages but no action by the victim.
User-imported settings file
A user can import a crafted overrides.json through the Import button in the Settings Editor, having received it from another party. This requires no privileges but a deliberate action by the victim, who reasonably expects a settings file to change preferences rather than run code.
Patches
JupyterLab 4.6.2 and 4.5.10 were patched.
Workarounds
None
Hardening
- Treat a settings file as something that can affect how JupyterLab behaves, not only how it appears. Administrators are encouraged to establish a trusted process for distributing configuration rather than relying on ad-hoc importing of shared files.
- On multi-tenant or shared file systems, restrict write permissions on the application settings directory and other Jupyter configuration paths so that one user cannot place an
overrides.json(or other configuration) readable by another user. A settings file in these locations is applied automatically, without an import step, so directory permissions are the primary control against cross-user tampering.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | jupyterlab | ≥ 4.6.0&&< 4.6.2 | 4.6.2 |
| 🐍PyPI | jupyterlab | ≥ 3.3.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-pppj-hq3g-57pj 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-pppj-hq3g-57pj 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-pppj-hq3g-57pj. 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-pppj-hq3g-57pj in your dependencies?
O3 detects GHSA-pppj-hq3g-57pj across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.