GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration

BREW-JUPYTERLAB-CVE-2026-73626 (GHSA-WHVH-WF3X-G77J)

Vulnerability from osv_homebrew – Published: 2026-08-14 09:11 – Updated: 2026-08-17 17:19 – Source website
VLAI
Summary
JupyterLab: Allowlist/blocklist check in `PyPIExtensionManager.install()` not enforced for direct callers (missing `await`)
Details

The extension allowlist/blocklist check inside PyPIExtensionManager.install() was not enforced due to a missing await. For purposes of JupyterLab this was a secondary defense-in-depth check: install() was intended to enforce the allowlist/blocklist itself for any future uses and users calling this method directly (in addition to the separate check handling requests arriving through the HTTP API). The only runtime symptom was a RuntimeWarning: coroutine 'is_install_allowed' was never awaited.

This has security implications only for deployments that combine all of the following: - a custom extension or downstream integration that imports PyPIExtensionManager and calls install() directly with a package name influenced by untrusted user input (the stock JupyterLab HTTP handler is not affected - it performs its own awaited allowlist check before calling install()); - an allowlist/blocklist configured with the intent of restricting which packages users can install; - the (default) PyPI Extension Manager enabled; and - kernels and terminals disabled or delegated to remote hosts, so that the custom extension's install() call is the only available package-install vector (otherwise a user with kernel access can install packages directly regardless of this check)

Impact

Low. No exposure for stock JupyterLab: the HTTP API and Extension Manager UI enforce the listing through a separate, correctly awaited check. The gap affected only custom extensions or downstream integrations that called the public install() method directly and relied on it to self-enforce.

Patches

JupyterLab v4.6.2 and v4.5.10 contain the patch.

Users of applications that depend on JupyterLab, such as Notebook v7+, should update jupyterlab package too.

Workarounds

No action is required for deployments that only expose extension management through the JupyterLab HTTP API / Extension Manager UI, as that path was already enforcing the listing via the handler's own check. Deployments wanting to disable programmatic extension installation entirely can switch to the read-only extension manager:

--LabApp.extension_manager=readonly

or the following traitlet:

c.LabApp.extension_manager = 'readonly'

You can confirm that the read-only manager is in use from GUI:

image


{
  "affected": [
    {
      "ecosystem_specific": {
        "fix": "bump",
        "range_state": "fixed",
        "upstream_fixed_in": "4.6.2"
      },
      "package": {
        "ecosystem": "Homebrew",
        "name": "jupyterlab",
        "purl": "pkg:brew/jupyterlab"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.6.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "confidence": "high",
    "source": "matched",
    "strategy": "registry",
    "upstream_evidence": [
      {
        "ecosystem": "PyPI",
        "key": "pkg:pypi/jupyterlab@4.6.3",
        "name": "jupyterlab",
        "strategy": "registry",
        "subject_version": "4.6.3"
      },
      {
        "ecosystem": "Debian",
        "key": "Debian/jupyterlab",
        "name": "jupyterlab",
        "strategy": "distro"
      },
      {
        "ecosystem": "PyPI",
        "key": "upstream:pkg:pypi/jupyterlab@4.6.3",
        "name": "jupyterlab",
        "strategy": "distro",
        "subject_version": "4.6.3"
      },
      {
        "ecosystem": "Ubuntu",
        "key": "Ubuntu/jupyterlab",
        "name": "jupyterlab",
        "strategy": "distro"
      }
    ]
  },
  "details": "The extension allowlist/blocklist check inside `PyPIExtensionManager.install()` was not enforced due to a missing await. For purposes of JupyterLab this was a secondary defense-in-depth check: `install()` was intended to enforce the allowlist/blocklist itself for any future uses and users calling this method directly (in addition to the separate check handling requests arriving through the HTTP API).  The only runtime symptom was a `RuntimeWarning: coroutine \u0027is_install_allowed\u0027 was never awaited.`\n\nThis has security implications only for deployments that combine all of the following:\n- a custom extension or downstream integration that imports `PyPIExtensionManager` and calls `install()` directly with a package name influenced by untrusted user input (the stock JupyterLab HTTP handler is not affected - it performs its own awaited allowlist check before calling `install()`);\n- an allowlist/blocklist configured with the intent of restricting which packages users can install;\n- the (default) PyPI Extension Manager enabled; and\n- kernels and terminals disabled or delegated to remote hosts, so that the custom extension\u0027s `install()` call is the only available package-install vector (otherwise a user with kernel access can install packages directly regardless of this check)\n\n### Impact\n\nLow. No exposure for stock JupyterLab: the HTTP API and Extension Manager UI enforce the listing through a separate, correctly awaited check. The gap affected only custom extensions or downstream integrations that called the public `install()` method directly and relied on it to self-enforce.\n\n### Patches\n\nJupyterLab [`v4.6.2`](https://github.com/jupyterlab/jupyterlab/releases/tag/v4.6.2) and [`v4.5.10`](https://github.com/jupyterlab/jupyterlab/releases/tag/v4.5.10) contain the patch.\n\nUsers of applications that depend on JupyterLab, such as Notebook v7+, should update `jupyterlab` package too.\n\n### Workarounds\n\nNo action is required for deployments that only expose extension management through the JupyterLab HTTP API / Extension Manager UI, as that path was already enforcing the listing via the handler\u0027s own check. Deployments wanting to disable programmatic extension installation entirely can switch to the read-only extension manager:\n\n```bash\n--LabApp.extension_manager=readonly\n```\n\nor the following traitlet:\n\n```python\nc.LabApp.extension_manager = \u0027readonly\u0027\n```\n\nYou can confirm that the read-only manager is in use from GUI:\n\n\u003cimg width=\"293\" height=\"293\" alt=\"image\" src=\"https://github.com/user-attachments/assets/8016c809-633e-4ed0-a5bc-6bc4793caa0f\" /\u003e",
  "id": "BREW-jupyterlab-CVE-2026-73626",
  "modified": "2026-08-17T17:19:28Z",
  "published": "2026-08-14T09:11:49Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/jupyterlab/jupyterlab/security/advisories/GHSA-whvh-wf3x-g77j"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jupyterlab/jupyterlab/pull/19184"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jupyterlab/jupyterlab/pull/19185"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jupyterlab/jupyterlab/pull/19186"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jupyterlab/jupyterlab/commit/be9303f5bcd5308eaeae953c5a3c903046682c2c"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jupyterlab/jupyterlab/commit/f1beab4a2027af4719d6edc07d52d6cf5a39a432"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jupyterlab/jupyterlab"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jupyterlab/jupyterlab/releases/tag/v4.5.10"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jupyterlab/jupyterlab/releases/tag/v4.6.2"
    }
  ],
  "schema_version": "1.7.3",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "JupyterLab: Allowlist/blocklist check in `PyPIExtensionManager.install()` not enforced for direct callers (missing `await`)",
  "upstream": [
    "GHSA-whvh-wf3x-g77j",
    "CVE-2026-73626"
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.


Loading…