JupyterLab vulnerable to potential authentication and CSRF tokens leakGHSA-44cc-43rp-5947
HIGHFix: jupyterlab/jupyterlab@19bd9b9GHSA-44cc-43rp-5947 is a high-severity (CVSS 7.6) CWE-23 vulnerability in jupyterlab. A fix is available for jupyterlab — see the affected versions and patch details below.
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-44cc-43rp-5947.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
Where this sits among everything scored
Real-World Exposure
jupyterlab🐍jupyterlab🐍notebookReal-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
Impact
Users of JupyterLab who click on a malicious link may get their Authorization and XSRFToken tokens exposed to a third party when running an older jupyter-server version.
Patches
JupyterLab 4.1.0b2, 4.0.11, and 3.6.7 were patched.
Workarounds
No workaround has been identified, however users should ensure to upgrade jupyter-server to version 2.7.2 or newer which includes a redirect vulnerability fix.
References
Vulnerability reported by user @davwwwx via the bug bounty program sponsored by the European Commission and hosted on the Intigriti platform.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | jupyterlab | ≥ 4.0.0&&< 4.0.11 | 4.0.11pip install --upgrade 'jupyterlab==4.0.11' |
| 🐍PyPI | jupyterlab | all versions | 3.6.7pip install --upgrade 'jupyterlab==3.6.7' |
| 🐍PyPI | notebook | ≥ 7.0.0&&< 7.0.7 | 7.0.7pip install --upgrade 'notebook==7.0.7' |
Affected Products
fedorafedoraprojectjupyterlabjupyternotebookjupyterDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for jupyterlab, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update jupyterlab to 4.0.11 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-44cc-43rp-5947 is resolved across your whole dependency graph.
Workarounds
Assume what was exposed is already known: rotate any credential, token or key that the affected component could return, restrict the endpoint to callers that genuinely need it, and strip sensitive fields from responses and error output at the boundary rather than relying on the client not to read them.
Frequently Asked Questions
Is GHSA-44cc-43rp-5947 in your dependencies?
Find it across PyPI, including transitive dependencies.