GHSA-WHVH-WF3X-G77J: Improper Access Control and Listing Bypass in JupyterLab Extension Manager

JupyterLab incorporates an extension manager that permits administrators and users to install additional packages from the Python Package Index (PyPI) to extend frontend and backend capabilities. To ensure secure operation in multi-tenant or enterprise environments, JupyterLab provides configuration settings to define allowlists or blocklists. These lists restrict the specific extension packages that users are permitted to deploy to the server instance.

The vulnerability tracked as GHSA-WHVH-WF3X-G77J represents a complete breakdown in this access control boundary. In the default PyPIExtensionManager, the validation layer designed to intercept and prevent prohibited installation calls does not execute properly within the install() function. Instead, Python's runtime behavior causes the code to bypass the validation conditional check entirely.

This vulnerability is categorized under CWE-284 (Improper Access Control) and CWE-636 (Not Failing Securely). The exposure is highly dependent on deployment configuration. While standard out-of-the-box installations filter requests at the HTTP routing tier, custom downstream integrations or direct programmatic calls to the manager APIs are left completely unprotected by this failure.

The fundamental flaw in jupyterlab/extensions/pypi.py centers on the improper execution of asynchronous code. The method responsible for installing packages, PyPIExtensionManager.install(), is defined as a standard Python asynchronous function (async def). Within its body, it evaluates authorization by invoking self.is_install_allowed(name, version).

Because is_install_allowed is itself an asynchronous function, executing it simply as a function call—without prefixing it with the await keyword—returns a Python coroutine object rather than its resolved boolean result. In Python, any object context evaluated by a conditional check defaults to a truthy value unless the object explicitly implements a false evaluation, which coroutine objects do not. Therefore, the conditional expression if not self.is_install_allowed(name, version) is evaluated as if not <coroutine_object>, resolving to if not True, which becomes False and bypasses the error-handling block.

Additionally, a secondary vulnerability exists due to a lack of canonicalization. When looking up package names in the allowlist or blocklist cache, JupyterLab used an identity-preserving normalizer that returned the raw input. Under PEP 503 rules, PyPI treats characters like hyphens, dots, and underscores as equivalent. An administrator blocking jupyterlab-git could have their security policy bypassed if a user requested installation of JupyterLab_Git because the server compared raw strings but the downstream installer (pip) fetched and executed the blocked package anyway.

An analysis of the vulnerable source code in jupyterlab/extensions/pypi.py highlights the logical error. The validation block was implemented as follows:

# Vulnerable implementation in jupyterlab/extensions/pypi.py
async def install(self, name: str, version: Optional[str] = None) -> ActionResult:
    # ... configuration loading ...
    if not self.is_install_allowed(name, version):
        # This block is unreachable because the coroutine object is truthy
        return ActionResult(status="error", message="install is not allowed")

To resolve this issue, the patch inserts the missing await operator to ensure the coroutine resolves to a boolean before negation. It also replaces the basic _normalize_name placeholder method with proper PEP 503 package canonicalization using the packaging.utils.canonicalize_name utility:

# Patched implementation showing corrected await and canonicalization
@override
async def install(self, name: str, version: Optional[str] = None) -> ActionResult:
    # ... configuration loading ...
    if not await self.is_install_allowed(name, version):
        # The await keyword forces execution and returns the true boolean value
        return ActionResult(status="error", message="install is not allowed")

For this vulnerability to be exploitable, specific conditions must align. The stock JupyterLab application employs an HTTP endpoint handler that runs its own properly-awaited checks before initiating the installation process. Thus, an attacker interacting solely with an unmodified stock JupyterLab HTTP REST API cannot exploit this flaw directly.

However, in enterprise environments, JupyterLab is commonly customized with downstream extensions, multi-tenant launching frameworks, or tailored administration consoles. If these custom implementations invoke PyPIExtensionManager.install() programmatically and rely on the manager to self-enforce the configure policy, the bypass is active. An attacker who has low-privileged user-level access to these custom components can request a restricted package name.

To execute a canonicalization bypass, the attacker targets the blocklist dictionary. If an administrator blocks restricted-extension, the attacker requests Restricted_Extension. Due to the lack of proper canonicalization, the string check fails to match the blocklist entry. The execution proceeds to pip, which normalizes the name to restricted-extension and installs the package, successfully achieving privilege escalation or execution of prohibited capabilities on the server hosting the JupyterLab instance.

The overall impact of this vulnerability is categorized as Low, resulting in a CVSS v3.1 score of 0.0. This score reflects the default state of JupyterLab, where the primary HTTP endpoints are secured by independent pre-checks. The vulnerability represents a loss of defense-in-depth, as the internal API does not fail securely when accessed directly by downstream software.

The real-world impact rises in scenarios where third-party JupyterLab integrations are deployed. In these scenarios, the vulnerability permits bypass of administrative controls. This allows unauthorized package installations on the host system, which could lead to remote code execution in the context of the JupyterLab server process.

No exploitation in the wild or weaponized proof-of-concept material has been observed. Additionally, the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog, nor is there any evidence of its use in active ransomware campaigns.

The primary remediation strategy is upgrading the underlying jupyterlab installation to a patched version. Security patches have been backported to both the 4.5.x and 4.6.x release streams. Administrators should transition environments to version 4.5.10 or 4.6.2 respectively.

If patching is not immediately feasible, administrators can apply workarounds. The risk can be mitigated by disabling the default extension manager UI or changing its operational state to read-only mode. This configuration removes the installation code path entirely, preventing potential misuse by users.

To enforce the read-only mode, launch the server with the explicit CLI argument --LabApp.extension_manager=readonly. Alternatively, add the configuration line c.LabApp.extension_manager = 'readonly' to the system-wide jupyter_server_config.py file. This prevents any PyPI installation actions from executing on the server.