GHSA-vmhf-c436-hxj4
JupyterLab: Stored XSS in extension manager through package metadata unsanitized URI protocol
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
A malicious PyPI package can place a javascript: URL in its [project.urls] metadata. JupyterLab's Extension Manager renders this as the extension's home-page link without validating the protocol, so a user who clicks the extension name executes attacker-controlled JavaScript in the JupyterLab origin.
Details
One of the PyPI package's URL (jupyterlab/extensions/pypi.py) is copied straight into the homepage_url rendered by the frontend in packages/extensionmanager/src/widget.tsx#L77-L88.
best_guess_home_url = (
homepage_url # home_page / [project.urls] Homepage
or data.get("project_url")
or data.get("package_url")
or documentation_url # docs_url / [project.urls] Documentation
or source_url # [project.urls] Source Code
or bug_tracker_url # bugtrack_url / [project.urls] Bug Tracker
)
# homepage_url=best_guess_home_url
{entry.homepage_url ? (
<a href={entry.homepage_url} target="_blank" rel="noopener noreferrer" ...>
{entry.name}
</a>
) : ( <div>{entry.name}</div> )}
Impact
An attacker needs to publish a package to PyPI (no access to the target). When the package appears in a victim's extension manager list and the victim clicks the extension name, the payload runs in the JupyterLab origin.
Preconditions: Extension Manager enabled with the default PyPI source, the malicious package appears in the victim's list/search results.
Patches
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | jupyterlab | all versions | 4.5.9 |
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.9 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-vmhf-c436-hxj4 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-vmhf-c436-hxj4 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-vmhf-c436-hxj4. 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-vmhf-c436-hxj4 in your dependencies?
O3 detects GHSA-vmhf-c436-hxj4 across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.