GHSA-h5v5-8746-g7mm: Jupyter plugin lock bypass

Q: Is GHSA-h5v5-8746-g7mm actively exploited?

No confirmed active exploitation of GHSA-h5v5-8746-g7mm has been reported, but organizations should still patch proactively.

Q: How to fix GHSA-h5v5-8746-g7mm?

1) Upgrade jupyterlab to v4.6.2 or v4.5.10 as soon as possible; if running Notebook v7+, update the jupyterlab dependency it pulls in as well. 2) Until patched, do not rely on 'lock all' or on locking a parent extension to cover its child plugins — manually enumerate and lock every core plugin ID (per JupyterLab docs) and every installed extension's individual plugin IDs via Plugin Manager. 3) For detection, monitor server logs for direct calls to /lab/api/plugins that enable/disable plugins outside the expected admin workflow, especially from non-admin authenticated sessions. 4) Review whether any data-loss-prevention controls (download/upload restrictions) were implemented solely via plugin locking, and add a compensating control (e.g., network-level egress restrictions) until all environments are patched.

Q: What systems are affected by GHSA-h5v5-8746-g7mm?

This vulnerability affects the following AI/ML architecture patterns: Jupyter/notebook-based ML development environments, multi-tenant JupyterHub deployments, training data pipelines.

Q: What is the CVSS score for GHSA-h5v5-8746-g7mm?

No CVSS score has been assigned yet.

CISO Take

JupyterLab's Plugin Manager lets administrators lock down which extensions users can enable or disable, but two server-side enforcement gaps mean an already-authenticated user can call the /lab/api/plugins endpoint directly to re-enable child plugins of multi-plugin extensions, or override an admin's 'lock all' directive entirely. There is no CVSS score, no EPSS data, no public exploit, and it is not in CISA KEV, and the requirement for prior authentication keeps exposure narrow — but the package has 1,876 downstream dependents and a mediocre OpenSSF Scorecard of 5.8/10, so the tooling itself is widely relied upon. The real risk is governance failure rather than remote takeover: any organization using Plugin Manager to enforce restrictions such as disabling file upload/download in a shared, regulated data science environment can have that control silently bypassed by the very users it was meant to restrict, undermining data-handling policy without leaving an obvious trace. Patch to jupyterlab 4.6.2 or 4.5.10 immediately — Notebook v7+ deployments must update the jupyterlab dependency too — and until patched, manually lock every core and extension plugin ID individually rather than relying on child-plugin inheritance or the 'lock all' shortcut, and audit /lab/api/plugins requests for unexpected enable/disable actions by non-admin users.

Sources: GitHub Advisory OpenSSF CISA KEV ATLAS

What is the risk?

Medium severity with no assigned CVSS vector, no EPSS score, no known public exploit or Nuclei template, and no CISA KEV listing — this is not an actively or opportunistically exploited flaw and requires an existing authenticated account on the JupyterLab server (CWE-863: Incorrect Authorization, compounded by CWE-602: Client-Side Enforcement of Server-Side Security). Exploitability is trivial for anyone who already has a valid session, since it only requires a direct HTTP call to a documented API path rather than any AI/ML-specific technique. The exposure is concentrated in multi-tenant or shared JupyterHub/JupyterLab deployments where administrators rely on Plugin Manager locks as a compensating control for data governance — outside that context (e.g., single-user personal notebooks) the practical risk is negligible.

How does the attack unfold?

Authenticated Access

Adversary obtains or already holds a standard, non-admin authenticated account on a shared JupyterLab/JupyterHub server.

AML.T0012

Control Bypass

Adversary sends a direct request to /lab/api/plugins to enable a plugin locked by the administrator, exploiting the server-side enforcement gap for child plugins or 'lock all' cases.

Impact

With the previously locked plugin (e.g., file download/upload) re-enabled, the adversary exfiltrates sensitive datasets, model artifacts, or notebook outputs in violation of the organization's data governance controls.

AML.T0025

Authenticated Access

Adversary obtains or already holds a standard, non-admin authenticated account on a shared JupyterLab/JupyterHub server.

AML.T0012

Control Bypass

Adversary sends a direct request to /lab/api/plugins to enable a plugin locked by the administrator, exploiting the server-side enforcement gap for child plugins or 'lock all' cases.

Impact

With the previously locked plugin (e.g., file download/upload) re-enabled, the adversary exfiltrates sensitive datasets, model artifacts, or notebook outputs in violation of the organization's data governance controls.

AML.T0025

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Jupyter	pip	>= 4.6.0, <= 4.6.1	`4.6.2`
13.4K OpenSSF 5.8 1.9K dependents Pushed 9d ago 61% patched ~30d to patch Full package profile →
Jupyter Notebook	pip	—	No patch
13.4K OpenSSF 5.8 3.0K dependents Pushed 9d ago 85% patched ~92d to patch Full package profile →

How severe is it?

CVSS 3.1

N/A

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

Trivial

What should I do?

1 step

1) Upgrade jupyterlab to v4.6.2 or v4.5.10 as soon as possible; if running Notebook v7+, update the jupyterlab dependency it pulls in as well. 2) Until patched, do not rely on 'lock all' or on locking a parent extension to cover its child plugins — manually enumerate and lock every core plugin ID (per JupyterLab docs) and every installed extension's individual plugin IDs via Plugin Manager. 3) For detection, monitor server logs for direct calls to /lab/api/plugins that enable/disable plugins outside the expected admin workflow, especially from non-admin authenticated sessions. 4) Review whether any data-loss-prevention controls (download/upload restrictions) were implemented solely via plugin locking, and add a compensating control (e.g., network-level egress restrictions) until all environments are patched.

How is it classified?

Auth Bypass Data Leakage Plugin AML.T0025 - Exfiltration via Cyber Means

Which compliance frameworks are affected?

This CVE is relevant to:

ISO 42001

A.6.2.6 - AI system operation and monitoring

NIST AI RMF

GOVERN 1.5 - Ongoing monitoring and periodic review of risk management processes

Frequently Asked Questions

What is GHSA-h5v5-8746-g7mm?

JupyterLab's Plugin Manager lets administrators lock down which extensions users can enable or disable, but two server-side enforcement gaps mean an already-authenticated user can call the /lab/api/plugins endpoint directly to re-enable child plugins of multi-plugin extensions, or override an admin's 'lock all' directive entirely. There is no CVSS score, no EPSS data, no public exploit, and it is not in CISA KEV, and the requirement for prior authentication keeps exposure narrow — but the package has 1,876 downstream dependents and a mediocre OpenSSF Scorecard of 5.8/10, so the tooling itself is widely relied upon. The real risk is governance failure rather than remote takeover: any organization using Plugin Manager to enforce restrictions such as disabling file upload/download in a shared, regulated data science environment can have that control silently bypassed by the very users it was meant to restrict, undermining data-handling policy without leaving an obvious trace. Patch to jupyterlab 4.6.2 or 4.5.10 immediately — Notebook v7+ deployments must update the jupyterlab dependency too — and until patched, manually lock every core and extension plugin ID individually rather than relying on child-plugin inheritance or the 'lock all' shortcut, and audit /lab/api/plugins requests for unexpected enable/disable actions by non-admin users.

Is GHSA-h5v5-8746-g7mm actively exploited?

No confirmed active exploitation of GHSA-h5v5-8746-g7mm has been reported, but organizations should still patch proactively.

How to fix GHSA-h5v5-8746-g7mm?

1) Upgrade jupyterlab to v4.6.2 or v4.5.10 as soon as possible; if running Notebook v7+, update the jupyterlab dependency it pulls in as well. 2) Until patched, do not rely on 'lock all' or on locking a parent extension to cover its child plugins — manually enumerate and lock every core plugin ID (per JupyterLab docs) and every installed extension's individual plugin IDs via Plugin Manager. 3) For detection, monitor server logs for direct calls to /lab/api/plugins that enable/disable plugins outside the expected admin workflow, especially from non-admin authenticated sessions. 4) Review whether any data-loss-prevention controls (download/upload restrictions) were implemented solely via plugin locking, and add a compensating control (e.g., network-level egress restrictions) until all environments are patched.

What systems are affected by GHSA-h5v5-8746-g7mm?

This vulnerability affects the following AI/ML architecture patterns: Jupyter/notebook-based ML development environments, multi-tenant JupyterHub deployments, training data pipelines.

What is the CVSS score for GHSA-h5v5-8746-g7mm?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

Jupyter/notebook-based ML development environmentsmulti-tenant JupyterHub deploymentstraining data pipelines

MITRE ATLAS Techniques

AML.T0025 Exfiltration via Cyber Means

Compliance Controls Affected

ISO 42001: A.6.2.6

NIST AI RMF: GOVERN 1.5

What are the technical details?

Original Advisory

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`](https://github.com/jupyterlab/jupyterlab/releases/tag/v4.6.2) and [`v4.5.10`](https://github.com/jupyterlab/jupyterlab/releases/tag/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](https://jupyterlab.readthedocs.io/en/latest/extension/extension_points.html#core-plugins) and identifiers for all installed extensions are listed in the [Plugin Manager](https://jupyterlab.readthedocs.io/en/latest/user/extensions.html#managing-plugins-with-plugin-manager).

Exploitation Scenario

A data scientist with a standard (non-admin) account on a shared JupyterHub instance is subject to an admin-enforced Plugin Manager lock disabling the file-download extension, intended to prevent exfiltration of a regulated or proprietary training dataset. Because the lock was applied via 'lock all' or inherited from a parent extension with multiple child plugins, the enforcement only exists at the UI layer. The user sends a direct authenticated request to /lab/api/plugins re-enabling the download plugin, regains the ability to export files from the notebook server, and exfiltrates sensitive training data or model artifacts — all without triggering any alert, since from the server's perspective this looks like a normal authenticated API call.

Weaknesses (CWE)

CWE-602 Client-Side Enforcement of Server-Side Security Primary CWE-863 Incorrect Authorization Primary

CWE-602 — Client-Side Enforcement of Server-Side Security: The product is composed of a server that relies on the client to implement a mechanism that is intended to protect the server.

[Architecture and Design] For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server. Even though client-side checks provide minimal benefits with respect to server-side security, they are still useful. First, they can support intrusion detection. If the server receives input that should have been rejected by the client, then it may be an indication of an attack. Second, client-side error-checking can provide helpful feedback to the user about the expectations for valid input. Third, there may be a reduction in server-side processing time for accidental input errors, although this is typically a small savings.
[Architecture and Design] If some degree of trust is required between the two entities, then use integrity checking and strong authentication to ensure that the inputs are coming from a trusted source. Design the product so that this trust is managed in a centralized fashion, especially if there are complex or numerous communication channels, in order to reduce the risks that the implementer will mistakenly omit a check in a single code path.

Source: MITRE CWE corpus.