Threat Intelligence Database

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 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 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 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 occurs 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. This 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 from 4.5.9 up to 4.6.1 contain a flaw in the PyPIExtensionManager.install() method where an asynchronous allowlist/blocklist check is not properly awaited, causing the check to be skipped. This affects only deployments that directly call install() with untrusted input, have an allowlist/blocklist configured, the PyPI Extension Manager enabled, and kernels/terminals disabled or remote. The standard JupyterLab HTTP API and Extension Manager UI are not affected. The issue is fixed in versions 4.6.2 and 4.5.10.

JupyterLab before 4.5.9 contains a stored cross-site scripting vulnerability in the Extension Manager that fails to validate URI protocols in package metadata URLs. Attackers can publish malicious PyPI packages with javascript: URLs in project metadata that execute arbitrary JavaScript in the JupyterLab origin when users click the extension name.

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.

In Jupyter Notebook versions 7.0.0 through 7.5.5, JupyterLab versions 4.5.6 and earlier, and the corresponding @jupyter-notebook/help-extension and @jupyterlab/help-extension packages before 7.5.6 and 4.5.7, a stored cross-site scripting issue in the help command linker can be chained with attacker-controlled notebook content to steal authentication tokens with a single click. An attacker can craft a malicious notebook file containing elements that appear indistinguishable from legitimate controls and trigger execution when a user interacts with them. Successful exploitation allows theft of the user's authentication token and complete takeover of the Jupyter session through the REST API, including reading files, creating or modifying files, accessing kernels to execute arbitrary code, and creating terminals for shell access. This issue has been fixed in Notebook 7.5.6, JupyterLab 4.5.7, @jupyter-notebook/help-extension 7.5.6, and @jupyterlab/help-extension 4.5.7. As a workaround, disable the affected help extensions or set allowCommandLinker to false in the sanitizer configuration.