A vulnerability in JupyterLab versions 4.5.7 through 4.6.3 and related applications allows a user to mistakenly trust a different document than the one they clicked a command button in. This occurs because the trust prompt marks whichever document is current when the user responds, not necessarily the document containing the clicked button. Trusted documents run commands without further prompts, potentially allowing untrusted documents to execute commands without explicit user confirmation. The issue affects Markdown files and notebooks and can persist across sessions for notebooks due to saving the trusted state to disk. Patches are available in JupyterLab versions 4.6.4 and 4.5.11 and related dependent applications. Workarounds include disabling command linker or choosing "Run Once" instead of "Trust".
JupyterLab versions 4.1.0 through 4.5.9 and 4.6.0 through 4.6.1 contain a vulnerability that allows authenticated users to bypass plugin manager lock rules. This bypass is due to two server-side enforcement gaps, enabling users to enable or disable plugins that administrators have locked, including child plugins and those locked via the 'lock all' mechanism. The vulnerability can undermine data integrity and bypass restrictions such as download or upload limits enforced through locked plugins. The issue is fixed in versions 4.5.10 and 4.6.2.
JupyterLab versions 4.5.9 and earlier, as well as versions 4.6.0 through 4.6.1, contain a vulnerability in the PyPIExtensionManager.install() method where a missing await causes the allowlist/blocklist enforcement to be bypassed for direct callers. This affects only custom extensions or downstream integrations that invoke install() directly with untrusted input. The standard JupyterLab HTTP API and UI are not affected. The issue is considered low impact and has been fixed in versions 4.5.10 and 4.6.2. Typical deployments using the HTTP API or UI require no action, and disabling programmatic extension installation via the read-only extension manager is a viable workaround.
JupyterLab versions prior to 4.5.9 contain a stored cross-site scripting (XSS) vulnerability in the Extension Manager. This flaw arises because the Extension Manager does not properly validate URI protocols in package metadata URLs. Malicious PyPI packages can exploit this by including javascript: URLs in their metadata, which execute arbitrary JavaScript in the context of the JupyterLab origin when users click on the extension name.
JupyterLab versions from 3.3.0 up to but not including 4.5.10, and from 4.6.0 up to but not including 4.6.2, contain a cross-site scripting (XSS) vulnerability via crafted overrides.json settings files. This vulnerability arises because certain settings are not properly validated before being inserted into style content, allowing malicious code execution when a user imports a crafted settings file or when an attacker plants such a file in a shared location. The embedded code executes with the affected user's privileges and can read or modify notebooks, files, and execute code on the notebook server and connected kernels. The issue is fixed in versions 4.5.10 and 4.6.2.
JupyterLab versions prior to 4.5.10 and 4.6.2 contain a cross-site scripting (XSS) vulnerability in the ImageViewer component. The issue arises because the ImageViewer uses URL.createObjectURL for specially crafted SVG images and revokes the blob URL too early. This allows the image to retain an executable same-origin context when opened in the image viewer and then in a new browser tab. This vulnerability can lead to arbitrary code execution on the JupyterLab server. The vulnerability is fixed in versions 4.5.10 and 4.6.2.
JupyterLab versions from 4.5.0 up to but not including 4.5.10, and from 4.6.0 up to but not including 4.6.2, contain a vulnerability in the PyPI extension manager. The blocklist enforcement uses a weaker normalization method than PyPI's canonical package-name normalization, allowing an authenticated user to bypass the blocklist by requesting an equivalent package name variant. This lets the user install prohibited extensions, defeating integrity restrictions and potentially affecting availability without gaining additional read access. The issue is fixed in versions 4.5.10 and 4.6.2.
JupyterLab's plugin manager has a vulnerability that allows authenticated users to bypass administrator-imposed plugin lock rules via direct API requests. This bypass affects child plugins of multi-plugin extensions and scenarios where administrators issued a 'lock all' command. The flaw can undermine data integrity and circumvent restrictions implemented through locked plugins. Patches addressing this issue are available in JupyterLab versions 4.6.2 and 4.5.10. Users of dependent applications like Notebook v7+ should also update the jupyterlab package. As a workaround, administrators can manually lock all plugins that require restriction using documented plugin identifiers.
A missing await in JupyterLab's PyPIExtensionManager.install() method caused the allowlist/blocklist check to not be enforced for direct callers. This issue affects only custom extensions or downstream integrations that call install() directly with untrusted input and rely on this method to enforce package restrictions. The default JupyterLab HTTP API and UI are not affected as they perform their own awaited checks. The vulnerability is low severity and has been patched in JupyterLab versions 4.6.2 and 4.5.10.
### Impact
A stored Cross-Site Scripting (XSS) vulnerability in Jupyter Notebook allows attackers to steal authentication tokens from users who open malicious notebook files and interact with elements that the attacker can make look indistinguishable from legitimate controls (single click interaction).
The vulnerability enables complete account takeover through the Jupyter REST API, allowing the attacker to:
1. Read all files
2. Modify/create files
3. Access running kernels and execute arbitrary code
4. Create terminals for shell access
### Patches
Jupyter Notebook 7.5.6 and JupyterLab 4.5.7 include patches for this vulnerability.
### Workarounds
The help extension can be disabled via CLI:
```
jupyter labextension disable @jupyter-notebook/help-extension
jupyter labextension disable @jupyterlab/help-extension
```
### Hardening
The patched versions include a toggle to disable the command linker functionality altogether, for example via `overrides.json`:
```json
{
"@jupyterlab/apputils-extension:sanitizer": {
"allowCommandLinker": false
}
}
```
### Resources
- https://jupyterlab.readthedocs.io/en/latest/user/commands.html#commands-in-markdown-output-and-files
### Acknowledgments
Reported by Daniel Teixeira - NVIDIA AI Red Team
CVE-2024-22420 is a cross-site scripting (XSS) vulnerability in JupyterLab that arises from improper neutralization of input during web page generation. The vulnerability can be triggered when a user opens a malicious notebook containing Markdown cells or previews a malicious Markdown file. Exploitation allows an attacker to access any data available to the victim and perform arbitrary requests on their behalf. JupyterLab version 4.0.11 includes a patch that addresses this issue. As a workaround, users can disable the table of contents extension to mitigate the risk.