https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Wed, 30 Sep 2026 22:39:39 +0000 https://vulnerability.circl.lu/vuln/brew-jupyterlab-cve-2026-73626 <p><strong>Affected:</strong> Homebrew: jupyterlab</p> <p>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 &#39;is_install_allowed&#39; was never awaited.`</p> <p>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&#39;s `install()` call is the only available package-install vector (otherwise a user with kernel access can install packages directly regardless of this check)</p> <p>### Impact</p> <p>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 i…</p> <p><strong>Affected:</strong> Homebrew: jupyterlab</p> <p>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 &#39;is_install_allowed&#39; was never awaited.`</p> <p>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&#39;s `install()` call is the only available package-install vector (otherwise a user with kernel access can install packages directly regardless of this check)</p> <p>### Impact</p> <p>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 i…</p> https://vulnerability.circl.lu/vuln/brew-jupyterlab-cve-2026-73626