CVE-2026-73626: JupyterLab: missing await bypasses extension allowlist

HIGH
Published August 13, 2026
CISO Take

A missing 'await' in JupyterLab's PyPIExtensionManager.install() means the allowlist/blocklist coroutine that vets extension packages before installation silently never runs, so blocked or unapproved PyPI packages can slip through when install() is called directly. The stock HTTP API and Extension Manager UI perform a separate, correctly-awaited check and are not affected, which narrows real-world exposure to organizations running custom extensions or downstream integrations that call install() directly with package names influenced by user input. Exploitation likelihood is low by every signal available: EPSS sits at 0.00181, there is no public exploit or Nuclei template, it is not in CISA KEV, and CISA's own SSVC decision is TRACK, the lowest-urgency bucket. With 1,886 downstream dependents on JupyterLab, the blast radius if this pattern is present is meaningful for any org running multi-tenant notebook services, but for most single-tenant deployments this is a low-priority patch. Upgrade to JupyterLab 4.6.2 or 4.5.10, and in the interim audit any custom code paths that call PyPIExtensionManager.install() directly to confirm they don't pass attacker-influenced package names.

Sources: NVD GitHub Advisory EPSS vulncheck.com ATLAS

What is the risk?

Low practical risk for the vast majority of deployments. The vulnerability is a logic defect (unawaited coroutine) rather than a network-reachable flaw in the shipped product surface — the official HTTP API and UI enforce the check correctly. It only becomes exploitable where an organization has built custom code on top of PyPIExtensionManager that calls install() directly with untrusted package names, has an allowlist/blocklist configured (implying they already care about restricting installable packages), has the PyPI Extension Manager enabled, and has kernels/terminals disabled or delegated to remote hosts (implying install() is one of few remaining ways to influence the environment). This is a narrow, specific configuration. CVSS is unscored (0.0) and EPSS (0.00181) places it far from active exploitation territory; SSVC TRACK confirms low urgency. No public PoC or scanner template exists.

How does the attack unfold?

Untrusted input reaches install()
A custom extension or downstream integration calls PyPIExtensionManager.install() directly with a package name influenced by untrusted user input.
AML.T0010.001
Allowlist check silently skipped
The unawaited is_install_allowed coroutine never executes, so the configured blocklist/allowlist check is bypassed without error.
AML.T0107
Unauthorized package installed
A package that should have been blocked (potentially malicious or typosquatted) installs into the JupyterLab environment.
AML.T0011.001
Code execution in AI dev environment
The installed package's code executes on import, giving the attacker a foothold inside the notebook/ML development session.
AML.T0112.001

What systems are affected?

Package Ecosystem Vulnerable Range Patched
Jupyter pip — No patch
13.4K OpenSSF 5.8 1.9K dependents Pushed 4d ago 57% patched ~35d to patch Full package profile →

Do you use Jupyter? You're affected.

How severe is it?

CVSS 3.1
0.0 / 10
EPSS
0.4%
chance of exploitation in 30 days
Higher than 28% of all CVEs
Exploitation Status
No known exploitation
Sophistication
Moderate

What is the attack surface?

AV AC PR UI S C I A
AV Network
AC Low
PR Low
UI None
S Unchanged
C None
I None
A None

What should I do?

1 step
  1. 1) Upgrade to JupyterLab 4.6.2 or 4.5.10, where the await is fixed and the allowlist/blocklist check is enforced for direct install() callers. 2) Audit any custom extensions, plugins, or downstream products that import PyPIExtensionManager and call install() directly — confirm package names passed to it are never derived from untrusted/user-controlled input without independent validation. 3) Until patched, add an explicit allowlist/blocklist check in your own wrapper code before calling install(), rather than relying solely on the library's internal enforcement. 4) For hardened/multi-tenant deployments, treat the kernel/terminal-disabled + extension-manager-allowlist combination as a defense-in-depth stack — verify other layers (network egress control to PyPI, package integrity scanning) are also in place rather than depending on a single control. 5) Detection: audit logs for unexpected PyPI installs of packages outside the configured allowlist in environments where this pattern applies.

What does CISA's SSVC say?

Decision Track
Exploitation none
Automatable No
Technical Impact partial

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

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act
Article 15 - Accuracy, robustness and cybersecurity
NIST AI RMF
GOVERN 6.1 - Third-party and supply chain risk policies
OWASP LLM Top 10
LLM03:2025 - Supply Chain Vulnerabilities

Frequently Asked Questions

What is CVE-2026-73626?

A missing 'await' in JupyterLab's PyPIExtensionManager.install() means the allowlist/blocklist coroutine that vets extension packages before installation silently never runs, so blocked or unapproved PyPI packages can slip through when install() is called directly. The stock HTTP API and Extension Manager UI perform a separate, correctly-awaited check and are not affected, which narrows real-world exposure to organizations running custom extensions or downstream integrations that call install() directly with package names influenced by user input. Exploitation likelihood is low by every signal available: EPSS sits at 0.00181, there is no public exploit or Nuclei template, it is not in CISA KEV, and CISA's own SSVC decision is TRACK, the lowest-urgency bucket. With 1,886 downstream dependents on JupyterLab, the blast radius if this pattern is present is meaningful for any org running multi-tenant notebook services, but for most single-tenant deployments this is a low-priority patch. Upgrade to JupyterLab 4.6.2 or 4.5.10, and in the interim audit any custom code paths that call PyPIExtensionManager.install() directly to confirm they don't pass attacker-influenced package names.

Is CVE-2026-73626 actively exploited?

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

How to fix CVE-2026-73626?

1) Upgrade to JupyterLab 4.6.2 or 4.5.10, where the await is fixed and the allowlist/blocklist check is enforced for direct install() callers. 2) Audit any custom extensions, plugins, or downstream products that import PyPIExtensionManager and call install() directly — confirm package names passed to it are never derived from untrusted/user-controlled input without independent validation. 3) Until patched, add an explicit allowlist/blocklist check in your own wrapper code before calling install(), rather than relying solely on the library's internal enforcement. 4) For hardened/multi-tenant deployments, treat the kernel/terminal-disabled + extension-manager-allowlist combination as a defense-in-depth stack — verify other layers (network egress control to PyPI, package integrity scanning) are also in place rather than depending on a single control. 5) Detection: audit logs for unexpected PyPI installs of packages outside the configured allowlist in environments where this pattern applies.

What systems are affected by CVE-2026-73626?

This vulnerability affects the following AI/ML architecture patterns: notebook/IDE development environments, multi-tenant ML development platforms, AI package/extension management tooling.

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

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

notebook/IDE development environmentsmulti-tenant ML development platformsAI package/extension management tooling

MITRE ATLAS Techniques

AML.T0010.001 AI Software
AML.T0011.001 Malicious Package
AML.T0107 Exploitation for Defense Evasion

Compliance Controls Affected

EU AI Act: Article 15
NIST AI RMF: GOVERN 6.1
OWASP LLM Top 10: LLM03:2025

What are the technical details?

Original Advisory

JupyterLab versions >=4.6.0,<=4.6.1 and <=4.5.9 contain an allowlist/blocklist enforcement gap in PyPIExtensionManager.install(). A missing 'await' caused the is_install_allowed coroutine to never execute, so the extension allowlist/blocklist check was not enforced for direct callers of install(). The stock JupyterLab HTTP API and Extension Manager UI are not affected, as they perform a separate, correctly awaited check. The issue affects only deployments where a custom extension or downstream integration imports PyPIExtensionManager and calls install() directly with a package name influenced by untrusted input, an allowlist/blocklist is configured, the PyPI Extension Manager is enabled, and kernels and terminals are disabled or delegated to remote hosts. Fixed in JupyterLab 4.6.2 and 4.5.10.

Exploitation Scenario

An organization runs a multi-tenant JupyterLab-based data science platform where end users cannot access kernels or terminals directly (delegated to remote compute), and instead interact through a custom internal tool that lets users request additional Python packages by name, calling PyPIExtensionManager.install() directly rather than going through the stock UI/API. The platform has a blocklist configured to prevent installation of known-malicious or typosquatted packages. Because the await is missing, the blocklist check never actually executes — a user (or an attacker who has phished/compromised such a user's session) requests installation of a typosquatted or backdoored package that should have been blocked. The package installs silently, and its malicious code executes on import within the user's notebook kernel environment, giving the attacker code execution and a foothold inside the AI development environment, including access to any credentials, datasets, or models present in that session.

Weaknesses (CWE)

CWE-284 — Improper Access Control: The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor.

  • [Architecture and Design, Operation] Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
  • [Architecture and Design] Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.

Source: MITRE CWE corpus.

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:N

Timeline

Published
August 13, 2026
Last Modified
August 28, 2026
First Seen
August 13, 2026

Related Vulnerabilities