Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
19 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
A Markdown file or a notebook output can carry a button that runs a JupyterLab command. Since 4.5.7 the first click on such a button opens a prompt naming the command, with Cancel, Run Once and Trust. Choosing Trust runs the command and marks the document trusted, so its later buttons run without a prompt. Which document gets marked is decided when the user answers, not when they click. Both trust commands read whichever document is current at that moment: markdownviewer:trust uses tracker.currentWidget, and notebook:trust uses the equivalent lookup. If another document becomes current while the prompt is open, that document is the one marked trusted, and the one the user was looking at stays untrusted. Users are affected if all of the following are true: - they run JupyterLab 4.5.7 through 4.6.3, or an application that bundles it such as Notebook 7.5+; - they open a Markdown file or notebook from someone else and click a button in it; - they answer Trust rather than…
Recommended action: Upgrade to 4.6.4 or 4.5.11 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A language pack ships a Plural-Forms header saying how the language counts, for example nplurals=2; plural=(n != 1);. JupyterLab turns that string into a function with new Function, so the header gets executed. The check that meant to keep it safe was a regular expression. The regex was anchored at the start but not at the end, so it accepted any string that began with a valid plural rule and ignored everything after it. A header such as the following passed the check, and the part after the plural rule ran in the JupyterLab page as soon as the first plural string was translated: Users are affected if all of the following are true: - they run JupyterLab 3.0.0 through 4.6.3, or an application that bundles it such as Notebook 7; - a language pack they did not write is installed in the environment; and - that language is selected, so its catalogue is loaded An installation using the default English locale loads no catalogue and is not affected. CVE assignment pending, GitHub…
Recommended action: Upgrade to 4.6.4 or 4.5.11 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
JupyterLab's PyPI extension manager runs python -m pip uninstall with the extension name taken from the request body. ExtensionHandler.post validates the name for cmd=install but not for cmd=uninstall, so a name that begins with - reaches the command line and pip reads it as an option rather than as a package. An extension name of the form -r followed by a path therefore made pip open that path as a requirements file. pip's parse error quotes the line it could not read and names the file it came from, and JupyterLab returned that error in the response body, so the line reached the requester. This has security implications only for deployments that combine all of the following: - the (default) PyPI Extension Manager enabled, so that uninstall requests reach pip; - an authenticated account permitted to call the extension API; and - kernels and terminals disabled or delegated to remote hosts (otherwise a user with kernel access can read the same files and make the same outbound requests…
Recommended action: Upgrade to 4.6.4 or 4.5.11 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
JupyterLab 4.5.0 enabled copying and pasing cells through the system clipboard. The paste path parses clipboard text as cell JSON and inserts the cells without clearing metadata.trusted, so a payload can declare its own output as trusted. JupyterLab does not sanitize a trusted output and evaluates the <script elements it contains, so pasting the cell runs attacker's JavaScript in the JupyterLab origin. The same payload with "trusted": false is sanitized. Users are affected if all of the following are true: - they run JupyterLab 4.5.0 through 4.6.3, or an application that bundles it such as Notebook 7.5+; - if running 4.5.2 or newer, useSystemClipboardForCells is enabled - it is off by default in 4.5.2+, and always enabled on 4.5.0 and 4.5.1 with no opt-out - they run a Paste Cells command (e.g. from context menu, command palette, shortcut) while attacker-controlled text is in the clipboard; and - pasteCodeCellsWithoutOutput is off, the default, so the pasted cell keeps…
Recommended action: Upgrade to 4.6.4 or 4.5.11 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
JupyterLab 4.5+ allows notebook settings to be shared and applied through an overrides.json file using the Import button in the Settings Editor. Certain notebook display settings were not properly validated before being applied. As a result, a crafted settings file could contain hidden instructions that run as code inside JupyterLab when imported, instead of only changing a display preference. Because importing a settings file appears harmless, a user could import a file shared by another party without realizing it could do more. On multi-tenant file systems without proper permission control, another user could plant a malicious overrides.json. CVE assignment pending, GitHub CNA is experiencing severe backlog Impact When a malicious settings file is applied, the embedded code runs with the same access as the affected user. This could allow an attacker to read or modify that user's notebooks and files, and to run code on the user's behalf through the notebook server, including on any…
Recommended action: Upgrade to 4.6.2 or 4.5.10 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
JupyterLab's image viewer allows for cross-site scripting (XSS) when a specially-crafted image file is opened through the image viewer and then opened in a new tab. This XSS issue can be used to cause remote code execution (RCE) on the JupyterLab server. Impact This vulnerability allows for arbitrary code execution. Patches JupyterLab v4.6.2 and v4.5.10 contain the patch. Workarounds Disable the image viewer plugin: Confirm with:
Recommended action: Upgrade to 4.6.2 or 4.5.10 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
JupyterLab's PyPI extension manager enforces blockedextensionsuris by comparing the requested install name to blocklist entries with a custom string normalization that is weaker 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; JupyterLab accepts the install request even though pip resolves the variant to the same package. This has security implications only for deployments that combine all of the following: - an allowlist/blocklist configured with the intent of restricting which packages users can install; - the (default) PyPI Extension Manager enabled; and - kernels and terminals disabled or delegated to remote hosts (otherwise a user with kernel access can install packages directly regardless of this check) Impact The vulnerability lets an authenticated user install a package the operator specifically intended to block, defeating the allowlist/blocklist…
Recommended action: Upgrade to 4.6.2 or 4.5.10 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
JupyterLab's plugin manager exposes administrator controls intended to prevent users from enabling or disabling selected plugins. Two server-side enforcement gaps let an authenticated user bypass those controls with direct requests to /lab/api/plugins. Impact Users could workaround the plugin manager lock rules via direct API access for either: - child plugins of extensions covering multiple plugins - when "lock all" was issued by the administrator The integrity of data can be impacted, and any hardening or restrictions on permitted user actions (e.g. download/upload limits) within the single-user server can be circumvented if those were implemented with plugins that were locked using the faulty mechanisms. Patches JupyterLab v4.6.2 and v4.5.10 contain the patch. Users of applications that depend on JupyterLab, such as Notebook v7+, should update jupyterlab package too. Workarounds Manually lock all plugins that should be locked. The core plugin identifiers can be found in the…
Recommended action: Upgrade to 4.6.2 or 4.5.10 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The extension allowlist/blocklist check inside PyPIExtensionManager.install() was not enforced due to a missing await. For purposes of JupyterLab this was a secondary defense-in-depth check: install() was intended to enforce the allowlist/blocklist itself for any future uses and users calling this method directly (in addition to the separate check handling requests arriving through the HTTP API). The only runtime symptom was a RuntimeWarning: coroutine 'isinstallallowed' was never awaited. This has security implications only for deployments that combine all of the following: - a custom extension or downstream integration that imports PyPIExtensionManager and calls install() directly with a package name influenced by untrusted user input (the stock JupyterLab HTTP handler is not affected - it performs its own awaited allowlist check before calling install()); - an allowlist/blocklist configured with the intent of restricting which packages users can install; - the (default) PyPI…
Recommended action: Upgrade to 4.6.2 or 4.5.10 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A malicious PyPI package can place a javascript: URL in its [project.urls] metadata. JupyterLab's Extension Manager renders this as the extension's home-page link without validating the protocol, so a user who clicks the extension name executes attacker-controlled JavaScript in the JupyterLab origin. Details One of the PyPI package's URL (jupyterlab/extensions/pypi.py) is copied straight into the homepageurl rendered by the frontend in packages/extensionmanager/src/widget.tsx#L77-L88. Impact An attacker needs to publish a package to PyPI (no access to the target). When the package appears in a victim's extension manager list and the victim clicks the extension name, the payload runs in the JupyterLab origin. Preconditions: Extension Manager enabled with the default PyPI source, the malicious package appears in the victim's list/search results. Patches Patched in 4.5.9, commits 4e61e07 and d5d961f
Recommended action: Upgrade to 4.5.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
JupyterLab's HTML sanitizer allowlists data-commandlinker-command and data-commandlinker-args on button elements, while CommandLinker listens for all click events on document.body and executes the named command without checking whether the element came from trusted JupyterLab UI. A notebook with a pre-saved HTML cell output containing a deceptive button can trigger arbitrary JupyterLab commands - including arbitrary code execution - on a single user click, without any code being submitted for execution by the user. Impact An attacker who shares a notebook or a Markdown file - via email, GitHub, or a Binder link - can invoke an arbitrary command upon a single click by the victim. The button can be rendered inside the output area and be visually indistinguishable from a legitimate widget. No kernel needs to start; the HTML output is stored in the notebook file and displayed immediately on open. Single-click impact An attacker convincing the victim to click on a single button or link…
Recommended action: Upgrade to 4.5.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The allow-list of extensions that can be installed from PyPI Extension Manager (allowedextensionsuris) is not correctly enforced by JupyterLab prior to 4.5.7. The PyPI Extension Manager was not contained to packages listed on the default PyPI index. This has security implications for deployments that: - have allow-listed specific extensions with aim to prevent users from installing packages - have the kernel and terminals disabled or delegated to remote hosts (thus no access to install packages in the single-user server environment) - have multi-tenant deployments that is not configured for untrusted users (as per documented on JupyterHub https://jupyterhub.readthedocs.io/en/5.2.1/explanation/websecurity.html) - have the (default) PyPI Extension Manager enabled Impact An authenticated attacker - such as a student in a shared JupyterHub environment or a user in a multi-tenant JupyterLab deployment - can escalate their privileges. This might allow for data exfiltration, lateral…
Recommended action: Upgrade to 4.5.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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: Hardening The patched versions include a toggle to disable the command linker functionality altogether, for example via overrides.json: 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
Recommended action: Upgrade to 4.5.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Links generated with LaTeX typesetters in Markdown files and Markdown cells in JupyterLab and Jupyter Notebook did not include the noopener attribute. This is deemed to have no impact on the default installations. Theoretically users of third-party LaTeX-rendering extensions could find themselves vulnerable to reverse tabnabbing attacks if: - links generated by those extensions included target=blank (no such extensions are known at time of writing) and - they were to click on a link generated in LaTeX (typically visibly different from other links). For consistency with handling on other links, new versions of JupyterLab will enforce noopener and target=blank on all links generated by typesetters. The former will harden the resilience of JupyterLab to extensions with lack of secure defaults in link rendering, and the latter will improve user experience by preventing accidental state loss when clicking on links rendered by LaTeX typesetters. Impact Since the official LaTeX typesetter…
Recommended action: Upgrade to 4.4.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The vulnerability depends on user interaction by opening a malicious notebook with Markdown cells, or Markdown file using JupyterLab preview feature. A malicious user can access any data that the attacked user has access to as well as perform arbitrary requests acting as the attacked user. Patches JupyterLab v3.6.8, v4.2.5 and Jupyter Notebook v7.2.2 were patched. Workarounds There is no workaround for the underlying DOM Clobbering susceptibility. However, select plugins can be disabled on deployments which cannot update in a timely fashion to minimise the risk. These are: - @jupyterlab/mathjax-extension:plugin - users will loose ability to preview mathematical equations - @jupyterlab/markdownviewer-extension:plugin - users will loose ability to open Markdown previews - @jupyterlab/mathjax2-extension:plugin (if installed with optional jupyterlab-mathjax2 package) - an older version of the mathjax plugin for JupyterLab 4.x To disable these extensions run: To confirm that the…
Recommended action: Upgrade to 4.2.5 or 3.6.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
JupyterLab extension template is a `copier` template for JupyterLab extensions. Repositories created using this template with `test` option include `update-integration-tests.yml` workflow which has an RCE vulnerability. Extension authors hosting their code on GitHub are urged to upgrade the template to the latest version. Users who made changes to `update-integration-tests.yml`, accept overwriting of this file and re-apply your changes later. Users may wish to temporarily disable GitHub Actions while working on the upgrade. We recommend rebasing all open pull requests from untrusted users as actions may run using the version from the `main` branch at the time when the pull request was created. Users who are upgrading from template version prior to 4.3.0 may wish to leave out proposed changes to the release workflow for now as it requires additional configuration.
Recommended action: Upgrade to 4.3.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Users of JupyterLab who click on a malicious link may get their Authorization and XSRFToken tokens exposed to a third party when running an older jupyter-server version. Patches JupyterLab 4.1.0b2, 4.0.11, and 3.6.7 were patched. Workarounds No workaround has been identified, however users should ensure to upgrade jupyter-server to version 2.7.2 or newer which includes a redirect vulnerability fix. References Vulnerability reported by user @davwwwx via the bug bounty program sponsored by the European Commission and hosted on the Intigriti platform.
Recommended action: Upgrade to 4.0.11 or 3.6.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The vulnerability depends on user interaction by opening a malicious notebook with Markdown cells, or Markdown file using JupyterLab preview feature. A malicious user can access any data that the attacked user has access to as well as perform arbitrary requests acting as the attacked user. Patches JupyterLab v4.0.11 was patched. Workarounds Users can either disable the table of contents extension by running: References Vulnerability reported via the bug bounty program sponsored by the European Commission and hosted on the Intigriti platform.
Recommended action: Upgrade to 4.0.11 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
3.0.172.2.101.2.213.1.42.3.2· Vendor fix available
Issue
Impact Untrusted notebook can execute code on load. This is a remote code execution, but requires user action to open a notebook. Patches Patched in the following versions: 3.1.4, 3.0.17, 2.3.2, 2.2.10, 1.2.21. References OWASP Page on Restricting Form Submissions For more information If you have any questions or comments about this advisory, or vulnerabilities to report, please email our security list security@ipython.org. Credit: Guillaume Jeanne from Google
Recommended action: Upgrade to 3.1.4, 3.0.17, 2.3.2 or 2 more by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.