GHSA-WHVH-WF3X-G77J
Vulnerability from github – Published: 2026-07-22 23:12 – Updated: 2026-07-22 23:12The 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:
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.6.1"
},
"package": {
"ecosystem": "PyPI",
"name": "jupyterlab"
},
"ranges": [
{
"events": [
{
"introduced": "4.6.0"
},
{
"fixed": "4.6.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.5.9"
},
"package": {
"ecosystem": "PyPI",
"name": "jupyterlab"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.5.10"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-284",
"CWE-636"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-22T23:12:22Z",
"nvd_published_at": null,
"severity": "LOW"
},
"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 \u0027is_install_allowed\u0027 was never awaited.`\n\nThis has security implications only for deployments that combine all of the following:\n- 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()`);\n- an allowlist/blocklist configured with the intent of restricting which packages users can install;\n- the (default) PyPI Extension Manager enabled; and\n- kernels and terminals disabled or delegated to remote hosts, so that the custom extension\u0027s `install()` call is the only available package-install vector (otherwise a user with kernel access can install packages directly regardless of this check)\n\n### Impact\n\nLow. 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.\n\n### Patches\n\nJupyterLab [`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.\n\nUsers of applications that depend on JupyterLab, such as Notebook v7+, should update `jupyterlab` package too.\n\n### Workarounds\n\nNo 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\u0027s own check. Deployments wanting to disable programmatic extension installation entirely can switch to the read-only extension manager:\n\n```bash\n--LabApp.extension_manager=readonly\n```\n\nor the following traitlet:\n\n```python\nc.LabApp.extension_manager = \u0027readonly\u0027\n```\n\nYou can confirm that the read-only manager is in use from GUI:\n\n\u003cimg width=\"293\" height=\"293\" alt=\"image\" src=\"https://github.com/user-attachments/assets/8016c809-633e-4ed0-a5bc-6bc4793caa0f\" /\u003e",
"id": "GHSA-whvh-wf3x-g77j",
"modified": "2026-07-22T23:12:22Z",
"published": "2026-07-22T23:12:22Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/jupyterlab/jupyterlab/security/advisories/GHSA-whvh-wf3x-g77j"
},
{
"type": "WEB",
"url": "https://github.com/jupyterlab/jupyterlab/pull/19184"
},
{
"type": "WEB",
"url": "https://github.com/jupyterlab/jupyterlab/pull/19185"
},
{
"type": "WEB",
"url": "https://github.com/jupyterlab/jupyterlab/pull/19186"
},
{
"type": "WEB",
"url": "https://github.com/jupyterlab/jupyterlab/commit/be9303f5bcd5308eaeae953c5a3c903046682c2c"
},
{
"type": "WEB",
"url": "https://github.com/jupyterlab/jupyterlab/commit/f1beab4a2027af4719d6edc07d52d6cf5a39a432"
},
{
"type": "PACKAGE",
"url": "https://github.com/jupyterlab/jupyterlab"
},
{
"type": "WEB",
"url": "https://github.com/jupyterlab/jupyterlab/releases/tag/v4.5.10"
},
{
"type": "WEB",
"url": "https://github.com/jupyterlab/jupyterlab/releases/tag/v4.6.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "JupyterLab: Allowlist/blocklist check in `PyPIExtensionManager.install()` not enforced for direct callers (missing `await`)"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.