JupyterLab vulnerabilities

JupyterLab prior to 4.5.7 allows data-commandlinker-command and data-commandlinker-args attributes on button elements in its HTML sanitizer. CommandLinker executes commands on click without verifying the element's origin, enabling arbitrary command execution via a crafted notebook cell.

JupyterLab from version 3.3.0 to 4.5.10 and 4.6.2 has a vulnerability in notebook settings where sideBySideLeftMarginOverride and sideBySideRightMarginOverride are not properly validated before being inserted into style content. A crafted settings file can contain instructions that execute as code, and importing it or automatic application by an attacker can lead to code execution with the user's access.

JupyterLab from version 4.5.0 to 4.5.10 and 4.6.2 has a vulnerability in the PyPI extension manager. The enforcement of blocked_extensions_uris uses weaker normalization than PyPI package-name canonicalization. An authenticated user can request a PyPI-equivalent spelling such as JupyterLab.Git for a blocklisted package such as jupyterlab-git, bypassing the blocklist.

JupyterLab (pip package 'jupyterlab') versions >=4.1.0,<=4.5.9 and >=4.6.0,<=4.6.1 contain a plugin manager lock-rule enforcement bypass. Two server-side enforcement gaps allow an authenticated user to circumvent administrator lock rules by making direct requests to the /lab/api/plugins endpoint, enabling or disabling plugins that were locked — including child plugins of multi-plugin extensions and plugins locked via the 'lock all' mechanism. This can impact data integrity and bypass hardening or restrictions (e.g., download/upload limits) implemented through locked plugins. Fixed in versions 4.6.2 and 4.5.10.

JupyterLab versions >=4.6.0,<=4.6.1 and <=4.5.9 contain an allowlist/blocklist enforcement gap in PyPIExtensionManager.install(). A missing 'await' caused the is_install_allowed coroutine to never execute, so the extension allowlist/blocklist check was not enforced for direct callers of install(). The stock JupyterLab HTTP API and Extension Manager UI are not affected, as they perform a separate, correctly awaited check. The issue affects only deployments where a custom extension or downstream integration imports PyPIExtensionManager and calls install() directly with a package name influenced by untrusted input, an allowlist/blocklist is configured, the PyPI Extension Manager is enabled, and kernels and terminals are disabled or delegated to remote hosts. Fixed in JupyterLab 4.6.2 and 4.5.10.

JupyterLab prior to 4.5.10 and 4.6.2 contains a cross-site scripting vulnerability in the ImageViewer component. A specially crafted SVG image opened in the image viewer and then in a new browser tab retains an executable same-origin context, allowing arbitrary code execution on the JupyterLab server.

JupyterLab before version 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 versions 4.0.0 through 4.5.6 do not correctly enforce the allowed extensions list (allowed_extensions_uris) in the PyPI Extension Manager. This allows installation of extensions from outside the default PyPI index, potentially leading to malicious code execution.