CVE-2026-73416: 
JupyterLab vulnerability analysis and mitigation

CVE-2026-73416 is a PyPI extension blocklist package-name canonicalization bypass vulnerability in JupyterLab that allows authenticated users to circumvent administrator-configured allow/blocklists for extension installation. The flaw exists in jupyterlab/extensions/manager.py and jupyterlab/extensions/pypi.py, where the extension manager uses a custom string normalization weaker than PyPI's canonical package-name normalization. Affected versions are JupyterLab >= 4.5.0 and < 4.5.10, and >= 4.6.0 and < 4.6.2. It was reported by researcher rexpository, remediated by krassowski, and published on July 21, 2026 (CVE assigned August 13, 2026). It carries a CVSS v4.0 base score of 6.1 (Medium) (GitHub Advisory).

The root cause is classified under CWE-178 (Improper Handling of Case Sensitivity) and CWE-180 (Incorrect Behavior Order: Validate Before Canonicalize). JupyterLab's _is_allowed_by_listing() method in manager.py called _normalize_name() — a weaker custom normalization — instead of PyPI's canonical canonicalize_name() function when comparing a requested package name against blocklist/allowlist entries. This meant that PyPI-equivalent spellings such as JupyterLab.Git, JupyterLab-Git, or jupyterlab_git for a blocklisted package like jupyterlab-git would pass the check, since pip resolves all variants to the same package. Additionally, is_install_allowed() was called without await in the install() method, meaning the check was not properly enforced. Exploitation requires: (1) an active allow/blocklist policy, (2) the default PyPI Extension Manager enabled, and (3) kernels and terminals disabled or delegated to remote hosts (GitHub Advisory, Patch PR).

Successful exploitation allows an authenticated user to install a package that an operator specifically intended to block, defeating the allowlist/blocklist access control. Since JupyterLab extensions can execute arbitrary code within the single-user server context, this enables untrusted users to impact the integrity and availability of their provisioned jupyter-server instance — for example, circumventing download/upload limits or other hardened restrictions. Confidentiality impact is limited (Low), as the user already has access to their own server's data and installing an extension grants no new read access. In JupyterHub deployments, availability impact is bounded to the user's own kernel pod, though resource exhaustion could potentially degrade shared resources where limits are absent (GitHub Advisory).

No public proof-of-concept exploit code or in-the-wild exploitation has been reported for this vulnerability. The EPSS score is 0.0, and it is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires authenticated access and a specific deployment configuration (active blocklist/allowlist, PyPI Extension Manager enabled, kernels/terminals restricted), which limits the practical attack surface (GitHub Advisory).

1. Identify target deployment: Confirm the JupyterLab instance runs a vulnerable version (>= 4.5.0 and < 4.5.10, or >= 4.6.0 and < 4.6.2) with the PyPI Extension Manager enabled and an active blocklist/allowlist policy.
2. Authenticate: Log in to the JupyterLab instance with valid user credentials (low-privilege authenticated access is sufficient).
3. Identify a blocked package: Determine which packages are on the blocklist (e.g., jupyterlab-git) by attempting a standard install and observing the denial response.
4. Craft a canonically equivalent name: Construct a PyPI-equivalent spelling of the blocked package that bypasses the weak normalization, such as JupyterLab.Git, JupyterLab-Git, or jupyterlab_git (using dots, mixed case, or underscores instead of hyphens).
5. Submit install request: Use the JupyterLab Extension Manager UI or API to request installation of the crafted package name (e.g., JupyterLab.Git).
6. Extension installs: JupyterLab's blocklist check passes because the custom normalization does not match the blocklist entry, while pip resolves the variant to the same blocked package and installs it.
7. Achieve objective: The installed extension executes arbitrary code within the single-user server context, allowing the attacker to circumvent operator-imposed restrictions on user actions (GitHub Advisory).

• Logs: JupyterLab server logs showing extension install requests with non-canonical package name spellings (e.g., JupyterLab.Git, JupyterLab-Git, jupyterlab_git) for packages that should be blocked; successful install confirmations for packages on the configured blocklist.
• File System: Unexpected extension packages present in the JupyterLab environment's site-packages directory that correspond to blocklisted packages; new or modified files in the JupyterLab extensions directory.
• Network: Outbound connections from the JupyterLab server to PyPI (pypi.org) to download packages with variant name spellings that resolve to blocklisted packages.

Upgrade JupyterLab to version 4.5.10 or 4.6.2 (or later), which replace the weak _normalize_name() with PyPI's canonical canonicalize_name() function and fix the missing await on is_install_allowed(). Users of dependent applications such as Notebook v7+ should also update the jupyterlab package. As an immediate workaround for deployments that do not require programmatic extension installation, switch to the read-only extension manager via --LabApp.extension_manager=readonly or by setting c.LabApp.extension_manager = 'readonly' in the traitlets configuration. No action is required for deployments without a custom allow/blocklist configured (GitHub Advisory, Patch PR).

The vulnerability was reported by researcher rexpository and remediated by JupyterLab maintainer krassowski, who noted a slight departure from the normal coordinated disclosure process due to GitHub private forks being broken at the time of the fix. The patch was bundled with fixes for four other JupyterLab security advisories (GHSA-gx64-gj6p-pc4c, GHSA-h5v5-8746-g7mm, GHSA-pppj-hq3g-57pj, GHSA-whvh-wf3x-g77j) in a single security release on July 21, 2026. No significant broader media coverage or social media discussion has been identified (GitHub Advisory, Patch PR).