CVE-2026-102831

JupyterLab is an extensible environment for interactive and reproducible computing, based on the Jupyter Notebook Architecture. From JupyterLab 3.0.0 until 4.5.11 and 4.6.4, and in JupyterLite Core 0.8.3 and earlier, the Plural-Forms header in a selected third-party language pack can append JavaScript after a valid plural rule because prefix-only regular-expression validation accepts a matching prefix without requiring the entire header to match. JupyterLab passes the accepted expression to new Function, so loading the catalogue and translating a plural string executes the appended code in the authenticated JupyterLab origin. Where Jupyter Server kernels, terminals, and APIs are exposed, the code can use authenticated server APIs to read or modify files and run code. Impact is much more limited in JupyterLite because it typically lacks most exposed Jupyter Server surfaces. The default English locale is unaffected because it does not load a translation catalogue. This issue is fixed in JupyterLab 4.5.11 and 4.6.4 and JupyterLite Core 0.8.4.

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 is an extensible environment for interactive and reproducible computing. From JupyterLab 4.0.0 until 4.5.11 and 4.6.4, the PyPI Extension Manager uninstall request reaches ExtensionHandler.post, which validates extension names for installation but passes uninstall names to PyPIExtensionManager.uninstall and python -m pip uninstall without rejecting option-like values. An authenticated user with extension API access can supply a pip requirements option to make the server read a local file or fetch an internal URL, and reflected parse errors can return the first unparsable line or response content.

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.