CVE-2026-73416: extension blocklist bypass

CISO Take

JupyterLab's PyPI Extension Manager enforces a blocklist of prohibited extensions, but its custom name-normalization logic is weaker than standard PyPI package-name canonicalization, so an authenticated user can request a differently cased or punctuated spelling — e.g. "JupyterLab.Git" instead of "jupyterlab-git" — and have it accepted even though pip resolves both to the identical package. This matters specifically where an organization relies on that blocklist as a real isolation boundary: multi-tenant JupyterHub or notebook-as-a-service platforms that deliberately disable or remote-delegate kernels and terminals to constrain what users can do. Exploitation likelihood is low in the near term — EPSS sits at 0.487% (top 60th percentile), the CVE is not in CISA KEV, and there is no public PoC or Nuclei template — and impact is bounded to integrity/availability since the bypass grants no new read access. Patch to JupyterLab 4.5.10 or 4.6.2 immediately; in the interim, audit `blocked_extensions_uris` entries against PEP 503 canonical names and monitor extension-install logs for oddly-cased or punctuated variants of banned packages.

Sources:NVDEPSSGitHub AdvisoryATLAS

What is the risk?

Moderate risk for organizations that operate shared/multi-tenant JupyterLab deployments (JupyterHub, notebook-as-a-service, managed data-science sandboxes) where a PyPI extension blocklist is the actual control preventing users from re-enabling disabled capabilities such as terminal or git access. Low risk for single-user or fully-trusted JupyterLab installs where no extension restriction policy is enforced. Exploitability is low-effort (no special tooling, just an alternate name spelling) but requires an already-authenticated account, and there is no evidence of active exploitation, public exploit code, or scanner coverage — EPSS (0.487%, ~60th percentile) and absence from CISA KEV both support a non-urgent-but-patch-soon posture.

How does the attack unfold?

Initial Access

Adversary already holds valid authenticated credentials on a shared JupyterLab/JupyterHub instance.

AML.T0012

Blocklist Evasion

User requests installation of a blocklisted extension using an alternate PyPI-equivalent spelling that the weak normalization logic fails to canonicalize and match.

AML.T0107

Impact

The blocklisted extension installs successfully, restoring capabilities (e.g. git/shell-adjacent access) the platform operator had deliberately restricted, defeating the integrity control without new read access.

Initial Access

Adversary already holds valid authenticated credentials on a shared JupyterLab/JupyterHub instance.

AML.T0012

Blocklist Evasion

User requests installation of a blocklisted extension using an alternate PyPI-equivalent spelling that the weak normalization logic fails to canonicalize and match.

AML.T0107

Impact

The blocklisted extension installs successfully, restoring capabilities (e.g. git/shell-adjacent access) the platform operator had deliberately restricted, defeating the integrity control without new read access.

How severe is it?

CVSS 3.1

N/A

EPSS

0.7%

chance of exploitation in 30 days

Higher than 52% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Trivial

What should I do?

1 step

1) Upgrade JupyterLab to 4.5.10 or 4.6.2, where blocklist comparison now uses correct PyPI canonicalization. 2) Until patched, treat the PyPI Extension Manager blocklist as non-authoritative — disable the PyPI Extension Manager entirely on environments where extension restriction is a hard security requirement, or restrict extension installation via network/proxy allowlisting instead of in-app blocklists. 3) Audit blocked_extensions_uris configuration for entries that rely on exact-string matching rather than canonical form. 4) Detection: review extension-install audit logs / pip install events on JupyterHub or notebook servers for install requests matching known blocklisted packages under alternate casing or punctuation (e.g. dots, underscores, mixed case).

What does CISA's SSVC say?

DecisionTrack

Exploitationnone

AutomatableNo

Technical Impactpartial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Auth BypassSupply ChainFrameworkPluginAML.T0010.001- AI Software

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 6.1-Policies and procedures address AI risks from third-party entities

OWASP LLM Top 10

LLM03:2025-Supply Chain Vulnerabilities

Frequently Asked Questions

What is CVE-2026-73416?

JupyterLab's PyPI Extension Manager enforces a blocklist of prohibited extensions, but its custom name-normalization logic is weaker than standard PyPI package-name canonicalization, so an authenticated user can request a differently cased or punctuated spelling — e.g. "JupyterLab.Git" instead of "jupyterlab-git" — and have it accepted even though pip resolves both to the identical package. This matters specifically where an organization relies on that blocklist as a real isolation boundary: multi-tenant JupyterHub or notebook-as-a-service platforms that deliberately disable or remote-delegate kernels and terminals to constrain what users can do. Exploitation likelihood is low in the near term — EPSS sits at 0.487% (top 60th percentile), the CVE is not in CISA KEV, and there is no public PoC or Nuclei template — and impact is bounded to integrity/availability since the bypass grants no new read access. Patch to JupyterLab 4.5.10 or 4.6.2 immediately; in the interim, audit `blocked_extensions_uris` entries against PEP 503 canonical names and monitor extension-install logs for oddly-cased or punctuated variants of banned packages.

Is CVE-2026-73416 actively exploited?

No confirmed active exploitation of CVE-2026-73416 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-73416?

1) Upgrade JupyterLab to 4.5.10 or 4.6.2, where blocklist comparison now uses correct PyPI canonicalization. 2) Until patched, treat the PyPI Extension Manager blocklist as non-authoritative — disable the PyPI Extension Manager entirely on environments where extension restriction is a hard security requirement, or restrict extension installation via network/proxy allowlisting instead of in-app blocklists. 3) Audit `blocked_extensions_uris` configuration for entries that rely on exact-string matching rather than canonical form. 4) Detection: review extension-install audit logs / pip install events on JupyterHub or notebook servers for install requests matching known blocklisted packages under alternate casing or punctuation (e.g. dots, underscores, mixed case).

What systems are affected by CVE-2026-73416?

This vulnerability affects the following AI/ML architecture patterns: notebook/data-science platforms, multi-tenant ML sandboxes, MLOps environments.

What is the CVSS score for CVE-2026-73416?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

notebook/data-science platformsmulti-tenant ML sandboxesMLOps environments

MITRE ATLAS Techniques

AML.T0010.001AI Software

Compliance Controls Affected

ISO 42001: A.6.2.6

NIST AI RMF: GOVERN 6.1

OWASP LLM Top 10: LLM03:2025

What are the technical details?

Original Advisory

jupyterlab is an extensible environment for interactive and reproducible computing, based on the Jupyter Notebook Architecture. From 4.5.0 until 4.5.10 and 4.6.2, in jupyterlab/extensions/manager.py and jupyterlab/extensions/pypi.py, JupyterLab's PyPI extension manager enforces blocked_extensions_uris by comparing requested install names to blocklist entries with custom 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, and JupyterLab accepts the install request even though pip resolves the variant to the same package. Security impact requires an allowlist or blocklist intended to restrict package installation, the PyPI Extension Manager, and kernels and terminals that are disabled or delegated to remote hosts. The bypass lets an authenticated user install a prohibited extension, defeat integrity restrictions, and affect availability without gaining new read access. This issue is fixed in versions 4.5.10 and 4.6.2.

Exploitation Scenario

On a shared JupyterHub instance where terminals and kernels are disabled and the platform blocklists `jupyterlab-git` (to prevent users from reintroducing git/shell-adjacent access), an authenticated data scientist requests installation of "JupyterLab.Git" via the PyPI Extension Manager UI or API. The blocklist comparison in `manager.py`/`pypi.py` normalizes this candidate name incorrectly and fails to match it against the canonical `jupyterlab-git` entry, so the install proceeds and pip silently resolves it to the exact same restricted package. The user now has the previously-blocked extension's capabilities inside an environment that was explicitly hardened to prevent that, defeating the operator's isolation control without needing any new credentials or read access.

Weaknesses (CWE)

CWE-178Improper Handling of Case SensitivityPrimary CWE-180Incorrect Behavior Order: Validate Before CanonicalizePrimary CWE-178Improper Handling of Case Sensitivity CWE-180Incorrect Behavior Order: Validate Before Canonicalize

CWE-178 — Improper Handling of Case Sensitivity: The product does not properly account for differences in case sensitivity when accessing or determining the properties of a resource, leading to inconsistent results.

[Architecture and Design] Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names.
[Implementation] Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylis

Source: MITRE CWE corpus.