CVE-2025-59842

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.

In JupyterLab from 4.5.7 until 4.5.11 and 4.6.4, the markdownviewer:trust and notebook:trust command-link handlers use tracker.currentWidget to resolve the current document rather than retaining the document whose command button was clicked. If another document becomes current while the prompt is open and the user chooses Trust, JupyterLab marks the second document trusted while leaving the clicked document untrusted. Later command buttons in the incorrectly trusted document run without a prompt, and trusting a notebook marks all cells trusted, saves unsaved edits, and persists the server signature to disk. Fixed in versions 4.5.11 and 4.6.4.

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 is an extensible environment for interactive and reproducible computing, based on the Jupyter Notebook Architecture. From JupyterLab 4.5.0 until 4.5.11 and 4.6.4, from Notebook 7.5.0 until 7.6.3, and from JupyterLite Core 0.7.0 until 0.8.4, the system clipboard cell-paste path accepts attacker-controlled cell JSON without clearing metadata.trusted. When useSystemClipboardForCells is active and pasteCodeCellsWithoutOutput is disabled, a pasted code cell can mark HTML output as trusted, bypass output sanitization, and execute script in the authenticated JupyterLab origin without executing the cell. Markdown and raw cells are not affected because their output is sanitized. This issue is fixed in JupyterLab 4.5.11 and 4.6.4, Notebook 7.6.3, and JupyterLite Core 0.8.4.

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.