Skip to content

chore(deps): update dependency jupyterlab to v4.6.2 [security]#860

Merged
renovate[bot] merged 1 commit into
developfrom
renovate/pypi-jupyterlab-vulnerability
Jul 23, 2026
Merged

chore(deps): update dependency jupyterlab to v4.6.2 [security]#860
renovate[bot] merged 1 commit into
developfrom
renovate/pypi-jupyterlab-vulnerability

Conversation

@renovate

@renovate renovate Bot commented Jul 23, 2026

Copy link
Copy Markdown
Contributor

This PR contains the following updates:

Package Change Age Confidence
jupyterlab (changelog) 4.6.1 → 4.6.2 age confidence

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 PluginManager lock-rule enforcement bypass

GHSA-h5v5-8746-g7mm

More information

Details

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 documentation and identifiers for all installed extensions are listed in the Plugin Manager.

Severity

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

References

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

JupyterLab: PyPI extension blocklist package-name canonicalization bypass

GHSA-89vp-jrxv-24w8

More information

Details

JupyterLab's PyPI extension manager enforces blocked_extensions_uris 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 control. Because extensions in principle allow for arbitrary code execution, this vulnerability enables untrusted users to impact the integrity and availability of the jupyter-server instance that was provisioned to them. The user already has access to their own single-user server's data, so installing an extension grants no new read access.

In particular, the integrity of data can be impacted, and any hardening or restrictions on permitted user actions (download/upload limits) within the single-user server can be circumvented. Availability impact on a JupyterHub deployment is limited: while a user can be expected to exhaust their own kernel pod's resources, this vulnerability makes it easier to also exhaust the single-user server resources or generate more requests to shared resources; where limits are absent, resource exhaustion could potentially degrade the wider deployment.

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 do not have a custom allow/block list configured. 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: 6.1 / 10 (Medium)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:H/VA:L/SC:N/SI:N/SA: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 @​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).

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: PyPI extension blocklist package-name canonicalization bypass

GHSA-89vp-jrxv-24w8

More information

Details

JupyterLab's PyPI extension manager enforces blocked_extensions_uris 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 control. Because extensions in principle allow for arbitrary code execution, this vulnerability enables untrusted users to impact the integrity and availability of the jupyter-server instance that was provisioned to them. The user already has access to their own single-user server's data, so installing an extension grants no new read access.

In particular, the integrity of data can be impacted, and any hardening or restrictions on permitted user actions (download/upload limits) within the single-user server can be circumvented. Availability impact on a JupyterHub deployment is limited: while a user can be expected to exhaust their own kernel pod's resources, this vulnerability makes it easier to also exhaust the single-user server resources or generate more requests to shared resources; where limits are absent, resource exhaustion could potentially degrade the wider deployment.

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 do not have a custom allow/block list configured. 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: 6.1 / 10 (Medium)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:H/VA:L/SC:N/SI:N/SA:N

References

This data is provided by OSV and 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 @​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 OSV and the GitHub Advisory Database (CC-BY 4.0).

JupyterLab PluginManager lock-rule enforcement bypass

GHSA-h5v5-8746-g7mm

More information

Details

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 documentation and identifiers for all installed extensions are listed in the Plugin Manager.

Severity

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

References

This data is provided by OSV and 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 OSV and 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 (None)
  • 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 OSV and the GitHub Advisory Database (CC-BY 4.0).

Release Notes

jupyterlab/jupyterlab (jupyterlab)

v4.6.2

Compare Source

4.6.2

(Full Changelog)

Security patches
Bugs fixed
Maintenance and upkeep improvements
Documentation improvements
Other merged PRs
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)

@​afshin (activity) | @​GagandeepSingh20 (activity) | @​jtpio (activity) | @​krassowski (activity) | @​MUFFANUJ (activity)

Configuration

📅 Schedule: (UTC)

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

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, 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 added the security label Jul 23, 2026
@renovate
renovate Bot merged commit 3754bd5 into develop Jul 23, 2026
2 checks passed
@renovate
renovate Bot deleted the renovate/pypi-jupyterlab-vulnerability branch July 23, 2026 07:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

security

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

0 participants