CVE-2026-73626 is an access control gap (CWE-284) in JupyterLab's PyPIExtensionManager.install(). A missing await meant the allowlist and blocklist check never ran for direct callers. The record rates it High at 7.5, but the advisory limits real exposure to custom integrations. Fixed in 4.6.2 and 4.5.10.
What's affected
The record says JupyterLab versions from 4.6.0 up to and including 4.6.1, and 4.5.9 and earlier, are affected. The GitHub advisory (GHSA-whvh-wf3x-g77j) lists 4.6.2 and 4.5.10 as patched.
The advisory is narrow about who is exposed. The stock JupyterLab HTTP API and the Extension Manager screen are not affected, because they run a separate check that is correctly awaited. You are affected only if all of these hold: a custom extension or downstream integration calls install() directly, the package name comes from untrusted input, an allowlist or blocklist is configured, and the PyPI Extension Manager is enabled.
Severity, as two sources state it. The record gives 7.5 (High) under CVSS 3.1. The advisory describes the check as a secondary, defence in depth control, and VulnCheck lists the CVE with a CVSS 4.0 score of 0.0 and severity none. Treat this as High on paper but low in practice for a stock install.
How to check if you're exposed
Find the version first.
jupyter lab --version
pip show jupyterlab
Then answer the four questions in the advisory. Search your extensions and any platform code that wraps JupyterLab for PyPIExtensionManager and install. Check whether you configured an allowlist or blocklist for extensions. If nothing in your code calls install() directly, the stock server is not exposed. A runtime warning that a coroutine named is_install_allowed was never awaited is the only symptom the advisory mentions, so you can also search logs for it.
What to do now
- Upgrade JupyterLab to 4.6.2 on the 4.6 line or 4.5.10 on the 4.5 line.
- Search custom extensions and hub integrations for direct calls to the install method.
- If you find one, make sure the allowlist check is awaited before the install, or route the call through the standard handler.
- Search logs for the never awaited coroutine warning.
- Keep the extension allowlist, since it is still your policy control. Do not drop it because this check failed.
Why it matters
The weakness is improper access control, CWE-284, caused by a missing await keyword. In Python, calling an async function without awaiting it creates a coroutine object and never runs the body. The policy check returned nothing, and the install carried on. The only visible sign was a runtime warning that most people never read.
It is a good reminder that a control can be present, tested in one path and silently skipped in another. Linters can catch un-awaited coroutines, and turning that warning into an error in your test settings would have caught it early. For defenders, the lesson is practical: the stock path was safe, the library API was not. The KEV flag for this record is false.
Quick check
Is a default JupyterLab install at risk?
The advisory says the stock HTTP API and Extension Manager screen are not affected. Only custom code calling install() directly is in scope.
Why does the record say 7.5 when the advisory sounds minor?
The record scores the flaw in the worst case, ignoring the preconditions. The advisory and VulnCheck weigh how few deployments meet them.
Sources
Last reviewed: 18 October 2026.
