Skip to content

chore(deps): update dependency jupyterlab to v4 [security] - #8

Open
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/pypi-jupyterlab-vulnerability
Open

chore(deps): update dependency jupyterlab to v4 [security]#8
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/pypi-jupyterlab-vulnerability

Conversation

@renovate

@renovate renovate Bot commented Apr 27, 2025

Copy link
Copy Markdown

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
jupyterlab (changelog) ==3.5.3==4.5.10 age adoption passing confidence

JupyterLab vulnerable to potential authentication and CSRF tokens leak

CVE-2024-22421 / GHSA-44cc-43rp-5947

More information

Details

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.

Severity

  • CVSS Score: 7.6 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:L

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


HTML injection in Jupyter Notebook and JupyterLab leading to DOM Clobbering

CVE-2024-43805 / GHSA-9q39-rmj3-p4r2

More information

Details

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:

jupyter labextension disable @​jupyterlab/markdownviewer-extension:plugin
jupyter labextension disable @​jupyterlab/mathjax-extension:plugin
jupyter labextension disable @​jupyterlab/mathjax2-extension:plugin

To confirm that the plugins were disabled run:

jupyter labextension list
References

None

Notes

This change has a potential to break rendering of some markdown. There is a setting in Sanitizer which allows to revert to the previous sanitizer settings (allowNamedProperties).

Severity

  • CVSS Score: 8.8 / 10 (High)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:L/VA:L/SC:N/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


JupyterLab LaTeX typesetter links did not enforce noopener attribute

CVE-2025-59842 / GHSA-vvfj-2jqx-52jm

More information

Details

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 extensions for JupyterLab: jupyterlab-mathjax (default), jupyterlab-mathjax2 and jupyterlab-katex do not include the target=_blank, there is no impact for JupyterLab users.

Patches

JupyterLab 4.4.8

Workarounds

No workarounds are necessary.

References

None

Severity

  • CVSS Score: 2.1 / 10 (Low)
  • Vector String: CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:A/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


Jupyter Notebook Vulnerable to Authentication Token Theft via CommandLinker XSS

CVE-2026-40171 / GHSA-rch3-82jr-f9w9

More information

Details

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:

jupyter labextension disable @​jupyter-notebook/help-extension
jupyter labextension disable @​jupyterlab/help-extension
Hardening

The patched versions include a toggle to disable the command linker functionality altogether, for example via overrides.json:

{
  "@​jupyterlab/apputils-extension:sanitizer": {
    "allowCommandLinker": false
  }
}
Resources
Acknowledgments

Reported by Daniel Teixeira - NVIDIA AI Red Team

Severity

  • CVSS Score: 8.4 / 10 (High)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


JupyterLab's command linker attributes in HTML enable one-click command execution from untrusted content

CVE-2026-42557 / GHSA-mqcg-5x36-vfcg

More information

Details

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 can:

  • execute arbitrary code in the available kernels,
  • delete files leading to information loss; in principle the loss could be unrecoverable, depending on server configuration and attack complexity,
  • open multiple kernels/terminals at once, or create multiple files at once, putting significant stress on the server and thus deny availability for other users when using standalone multi-tenant jupyter-server deployment, and to a lesser degree impact availability on JupyterHub deployments.

The arbitrary code execution will be immediately visible to the user; and can be halted by the timely user intervention. The deletion of files can be silent and go unnoticed for some time.

Multi-click attacks

An attacker who convinces the victim to click on multiple buttons in specific order and to grant access to clipboard (or in scenarios where the user already granted keyboard access) can obtain full access to the terminal and execute arbitrary commands in the environment with access scope that might exceed that of available kernels. Only users of Chromium-based browsers are susceptible to this expanded variant of the attack.

The execution of commands in the terminal would be immediately visible to the user.

Impact of third-party extensions

The impact described above assumes a plain JupyterLab/Notebook installation. In environments with frontend extensions that contribute additional commands the attack surface is increased by the functionality covered by these commands.

Patches

JupyterLab 4.5.7

Workarounds

No workarounds are available for end-users.

Downstream applications inheriting from JupyterFrontEnd or JupyterLab can effectively disable the CommandLinker by passing commandLinker: new CommandLinker({ commands: new CommandRegistry() }) option in the initialization options.

Hardening

The patched versions include a toggle to disable the command linker functionality altogether, for example via overrides.json:

{
  "@​jupyterlab/apputils-extension:sanitizer": {
    "allowCommandLinker": false
  }
}
Resources

Severity

  • CVSS Score: 8.6 / 10 (High)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


JupyterLab: Stored XSS in extension manager through package metadata unsanitized URI protocol

GHSA-vmhf-c436-hxj4

More information

Details

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 homepage_url rendered by the frontend in packages/extensionmanager/src/widget.tsx#L77-L88.

best_guess_home_url = (
    homepage_url            # home_page / [project.urls] Homepage
    or data.get("project_url")
    or data.get("package_url")
    or documentation_url    # docs_url / [project.urls] Documentation
    or source_url           # [project.urls] Source Code
    or bug_tracker_url      # bugtrack_url / [project.urls] Bug Tracker
)

##### homepage_url=best_guess_home_url
{entry.homepage_url ? (
  <a href={entry.homepage_url} target="_blank" rel="noopener noreferrer" ...>
    {entry.name}
  </a>
) : ( <div>{entry.name}</div> )}
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

Severity

  • CVSS Score: 5.1 / 10 (Medium)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


JupyterLab: Cross-site scripting (XSS) via crafted settings file (overrides.json)

GHSA-pppj-hq3g-57pj

More information

Details

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 connected kernel.

User Interaction vs Privileges Required
Write access to a loaded settings location

If an attacker can write to a directory JupyterLab loads settings from (e.g. on shared or multi-tenant file system), they could place a crafted overrides.json that is applied to another user automatically at startup. This requires high privilages but no action by the victim.

User-imported settings file

A user can import a crafted overrides.json through the Import button in the Settings Editor, having received it from another party. This requires no privileges but a deliberate action by the victim, who reasonably expects a settings file to change preferences rather than run code.

Patches

JupyterLab 4.6.2 and 4.5.10 were patched.

Workarounds

None

Hardening
  1. Treat a settings file as something that can affect how JupyterLab behaves, not only how it appears. Administrators are encouraged to establish a trusted process for distributing configuration rather than relying on ad-hoc importing of shared files.
  2. On multi-tenant or shared file systems, restrict write permissions on the application settings directory and other Jupyter configuration paths so that one user cannot place an overrides.json (or other configuration) readable by another user. A settings file in these locations is applied automatically, without an import step, so directory permissions are the primary control against cross-user tampering.

Severity

  • CVSS Score: 8.6 / 10 (High)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:L/SC:N/SI:N/SA:L

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


JupyterLab: Allowlist/blocklist check in PyPIExtensionManager.install() not enforced for direct callers (missing await)

GHSA-whvh-wf3x-g77j

More information

Details

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 'is_install_allowed' 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 Extension Manager enabled; and
  • kernels and terminals disabled or delegated to remote hosts, so that the custom extension's install() call is the only available package-install vector (otherwise a user with kernel access can install packages directly regardless of this check)
Impact

Low. No exposure for stock JupyterLab: the HTTP API and Extension Manager UI enforce the listing through a separate, correctly awaited check. The gap affected only custom extensions or downstream integrations that called the public install() method directly and relied on it to self-enforce.

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

No action is required for deployments that only expose extension management through the JupyterLab HTTP API / Extension Manager UI, as that path was already enforcing the listing via the handler's own check. Deployments wanting to disable programmatic extension installation entirely can switch to the read-only extension manager:

--LabApp.extension_manager=readonly

or the following traitlet:

c.LabApp.extension_manager = 'readonly'

You can confirm that the read-only manager is in use from GUI:

image

Severity

  • CVSS Score: 0.0 / 10 (Low)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


JupyterLab: Image viewer allows XSS when opening malicious image in new browser tab

GHSA-gx64-gj6p-pc4c

More information

Details

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:

jupyter labextension disable @&#8203;jupyterlab/imageviewer-extension:plugin

Confirm with:

jupyter labextension list

Severity

  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:A/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


Release Notes

jupyterlab/jupyterlab (jupyterlab)

v4.5.10

Compare Source

4.5.10

(Full Changelog)

Security patches
Bugs fixed
Maintenance and upkeep improvements
Contributors to this release

The following people contributed discussions, new ideas, code and documentation contributions, and review.
See our definition of contributors.

(GitHub contributors page for this release)

@​krassowski (activity) | @​MUFFANUJ (activity)

v4.5.9

Compare Source

4.5.9

(Full Changelog)

Bugs fixed
Contributors to this release

The following people contributed discussions, new ideas, code and documentation contributions, and review.
See our definition of contributors.

(GitHub contributors page for this release)

@​arun-357 (activity) | @​Darshan808 (activity) | @​krassowski (activity) | @​MUFFANUJ (activity) | @​Yann-P (activity)

v4.5.8

Compare Source

4.5.8

(Full Changelog)

Bugs fixed
Maintenance and upkeep improvements
Contributors to this release

The following people contributed discussions, new ideas, code and documentation contributions, and review.
See our definition of contributors.

(GitHub contributors page for this release)

@​AliMahmoudDev (activity) | @​CrafterKolyan (activity) | @​Darshan808 (activity) | @​krassowski (activity)

v4.5.7

Compare Source

4.5.7

(Full Changelog)

Security patches
Bugs fixed
Maintenance and upkeep improvements
Documentation improvements
Contributors to this release

The following people contributed discussions, new ideas, code and documentation contributions, and review.
See our definition of contributors.

(GitHub contributors page for this release)

@​Carreau (activity) | @​filipeoliveira05 (activity) | @​flaviomartins (activity) | @​itsmejay80 (activity) | @​jtpio (activity) | @​krassowski (activity) | @​martinRenou (activity) | @​MUFFANUJ (activity) | @​utsav-develops (activity)

v4.5.6

Compare Source

4.5.6

(Full Changelog)

Bugs fixed
Maintenance and upkeep improvements
Contributors to this release

The following people contributed discussions, new ideas, code and documentation contributions, and review.
See our definition of contributors.

(GitHub contributors page for this release)

@​agriyakhetarpal (activity) | @​IsabelParedes (activity) | @​jtpio (activity) | @​krassowski (activity) | @​soniya-malviy (activity) | @​tmetzl (activity)

v4.5.5

Compare Source

4.5.5

(Full Changelog)

Bugs fixed
Maintenance and upkeep improvements
Contributors to this release

The following people contributed discussions, new ideas, code and documentation contributions, and review.
See our definition of contributors.

(GitHub contributors page for this release)

@​apoorvdarshan (activity) | @​bollwyvl (activity) | @​itsmevichu (activity) | @​jasongrout (activity) | @​krassowski (activity)

v4.5.4

Compare Source

4.5.4

(Full Changelog)

Bugs fixed
Maintenance and upkeep improvements
Documentation improvements
Contributors to this release

The following people contributed discussions, new ideas, code and documentation contributions, and review.
See our definition of contributors.

(GitHub contributors page for this release)

@​brichet (activity) | @​ceasermikes002 (activity) | @​DeborahOlaboye (activity) | @​itsmevichu (activity) | @​jasongrout (activity) | @​jtpio (activity) | @​krassowski (activity) | @​Krish-876 (activity)

v4.5.3

Compare Source

4.5.3

(Full Changelog)

Bugs fixed
  • Fix error in console when the debugger switch from a module to another #​18352 (@​brichet)
  • Fix focus of replace buttons in the document search box [#​18362](h

Note

PR body was truncated to here.


Configuration

📅 Schedule: (UTC)

  • Branch creation
    • At any time (no schedule defined)
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate
renovate Bot force-pushed the renovate/pypi-jupyterlab-vulnerability branch from cddfcb6 to 121feb9 Compare September 27, 2025 07:28
@renovate renovate Bot changed the title chore(deps): update dependency jupyterlab to v3.6.8 [security] chore(deps): update dependency jupyterlab to v4 [security] Sep 27, 2025
@renovate
renovate Bot force-pushed the renovate/pypi-jupyterlab-vulnerability branch from 121feb9 to 34963cd Compare May 2, 2026 04:07
@renovate
renovate Bot force-pushed the renovate/pypi-jupyterlab-vulnerability branch from 34963cd to 934ea68 Compare June 24, 2026 11:50
@renovate
renovate Bot force-pushed the renovate/pypi-jupyterlab-vulnerability branch from 934ea68 to ed6f8cd Compare July 29, 2026 07:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants