<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://db.gcve.eu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-01T05:43:29.352134+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@gcve.eu</email>
  </author>
  <link href="https://db.gcve.eu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://db.gcve.eu/vuln/bit-jupyterlab-2026-73626</id>
    <title>BIT-jupyterlab-2026-73626 — JupyterLab before 4.6.2 Authentication Bypass via PyPIExtensionManager</title>
    <updated>2026-10-01T05:43:29.354035+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Bitnami: jupyterlab</p>
<p>JupyterLab versions &gt;=4.6.0,&lt;=4.6.1 and &lt;=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.</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/bit-jupyterlab-2026-73626"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/cve-2026-73626</id>
    <title>CVE-2026-73626 — JupyterLab before 4.6.2 Authentication Bypass via PyPIExtensionManager</title>
    <updated>2026-10-01T05:43:29.354139+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> jupyterlab</p>
<p>JupyterLab versions &gt;=4.6.0,&lt;=4.6.1 and &lt;=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.</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/cve-2026-73626"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/ghsa-whvh-wf3x-g77j</id>
    <title>GHSA-whvh-wf3x-g77j — JupyterLab: Allowlist/blocklist check in `PyPIExtensionManager.install()` not enforced for direct callers (missing `awa…</title>
    <updated>2026-10-01T05:43:29.354203+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PyPI: 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 'is_install_allowed' 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'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></div>
    </content>
    <link href="https://db.gcve.eu/vuln/ghsa-whvh-wf3x-g77j"/>
  </entry>
</feed>
