CVE-2026-73626: 
JupyterLab vulnerability analysis and mitigation

CVE-2026-73626 is an authorization bypass vulnerability in JupyterLab's PyPIExtensionManager.install() method caused by a missing await keyword that prevents the is_install_allowed coroutine from ever executing. This enforcement gap allows the extension allowlist/blocklist check to be silently skipped for any code that calls install() directly. Affected versions are JupyterLab >=4.6.0,<=4.6.1 and <=4.5.9; the vulnerability was disclosed on August 13, 2026, and fixed in versions 4.6.2 and 4.5.10. The CNA-assigned CVSS v3.1 base score is 0.0 (None), reflecting the highly constrained exploitation conditions, though the Feedly estimate categorizes it as HIGH given the policy-bypass nature of the flaw (GitHub Advisory, GitHub Advisory DB).

The root cause is classified as CWE-284 (Improper Access Control) and CWE-636 (Not Failing Securely / Failing Open). In Python's async/await model, calling a coroutine function without await returns a coroutine object that is never executed; in this case, is_install_allowed was called without await inside PyPIExtensionManager.install(), meaning the allowlist/blocklist validation was entirely skipped and the only observable symptom was a RuntimeWarning: coroutine 'is_install_allowed' was never awaited. The stock JupyterLab HTTP API and Extension Manager UI are unaffected because they perform their own correctly awaited allowlist check in the HTTP handler before ever calling install(). Exploitation requires a custom extension or downstream integration that imports PyPIExtensionManager and calls install() directly with attacker-influenced package names, an active allowlist/blocklist configuration, the PyPI Extension Manager enabled, and kernels/terminals disabled or delegated to remote hosts (GitHub Advisory).

An authenticated user with access to a vulnerable custom integration can bypass configured extension allowlist/blocklist controls and install arbitrary PyPI packages that would otherwise be blocked by policy. The direct impact is an integrity violation of the extension management policy; there is no direct confidentiality or availability impact as scored by the CNA. In environments where kernels and terminals are disabled specifically to limit code execution vectors, a successfully installed malicious PyPI extension could reintroduce arbitrary code execution capabilities, potentially enabling lateral movement or data exfiltration depending on the installed package's behavior (GitHub Advisory, GitHub Advisory DB).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the disclosure date (GitHub Advisory DB). The EPSS score is 0.0, and CISA's SSVC assessment classifies exploitation as "none" and the vulnerability as not automatable. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation is further constrained by the requirement for an authenticated attacker, a non-standard deployment configuration, and the presence of a custom integration that directly calls install() with untrusted input.

1. Identify a vulnerable deployment: Locate a JupyterLab instance running versions >=4.6.0,<=4.6.1 or <=4.5.9 that has a custom extension or downstream integration which imports PyPIExtensionManager and calls install() directly, with an allowlist/blocklist configured and kernels/terminals disabled.
2. Authenticate to the deployment: Obtain low-privileged authenticated access to the JupyterLab instance (e.g., via a user account in a multi-user JupyterHub deployment).
3. Interact with the vulnerable custom integration: Trigger the custom extension's code path that calls PyPIExtensionManager.install() directly, supplying a package name that would normally be blocked by the configured allowlist/blocklist.
4. Bypass enforcement: Because the await keyword is missing, the is_install_allowed coroutine never executes, and the package name is not validated against the allowlist/blocklist — the installation proceeds unchecked.
5. Install a malicious or blocked PyPI package: The attacker's chosen package (e.g., one containing malicious code) is installed into the JupyterLab environment, potentially enabling further code execution or persistence (GitHub Advisory).

• Logs: Python RuntimeWarning: coroutine 'is_install_allowed' was never awaited appearing in JupyterLab server logs, indicating the vulnerable code path was triggered.
• File System: Unexpected or policy-violating PyPI packages present in the JupyterLab Python environment (e.g., detectable via pip list or inspection of site-packages) that are not on the configured allowlist.
• Logs: JupyterLab extension installation events logged for packages that should have been blocked by the configured allowlist/blocklist policy.
• Process: Unexpected processes or network connections originating from the JupyterLab server process following an anomalous package installation event (GitHub Advisory).

Upgrade JupyterLab to version 4.6.2 (for the 4.6.x branch) or 4.5.10 (for the 4.5.x branch); users of downstream applications such as Notebook v7+ should also update the jupyterlab package. Deployments that only expose extension management through the standard JupyterLab HTTP API or Extension Manager UI require no immediate action, as those paths were already enforcing the allowlist/blocklist correctly. As a workaround, operators can switch to the read-only extension manager using --LabApp.extension_manager=readonly or by setting c.LabApp.extension_manager = 'readonly' in the traitlet configuration, which disables programmatic extension installation entirely. Custom extensions and downstream integrations should be audited for direct calls to PyPIExtensionManager.install() and updated to perform their own awaited allowlist/blocklist validation (GitHub Advisory).

The JupyterLab maintainer (krassowski) published the advisory on July 21, 2026, noting that the issue was considered low severity and that no CVE was initially requested due to the low severity and delays in GitHub CVE assignment. The advisory explicitly frames the flaw as a defense-in-depth gap rather than a primary security control failure, and credits researcher MUFFANUJ for discovery. No significant broader media coverage or notable community debate has been observed beyond the standard vulnerability database aggregation (GitHub Advisory).