https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 03:08:51 +0000 https://cve.radiocsirt.org/vuln/brew-jupyterlab-cve-2026-42266 <p><strong>Affected:</strong> Homebrew: jupyterlab</p> <p>The allow-list of extensions that can be installed from PyPI Extension Manager (`allowed_extensions_uris`) is not correctly enforced by JupyterLab prior to 4.5.7. The PyPI Extension Manager was not contained to packages listed on the default PyPI index.</p> <p>This has security implications for deployments that: - have allow-listed specific extensions with aim to prevent users from installing packages - have the kernel and terminals disabled or delegated to remote hosts (thus no access to install packages in the single-user server environment) - have multi-tenant deployments that is not configured for untrusted users (as per documented on JupyterHub https://jupyterhub.readthedocs.io/en/5.2.1/explanation/websecurity.html) - have the (default) PyPI Extension Manager enabled</p> <p>### Impact</p> <p>An authenticated attacker - such as a student in a shared JupyterHub environment or a user in a multi-tenant JupyterLab deployment - can escalate their privileges. This might allow for data exfiltration, lateral movement within the network, and persistent compromise of the server infrastructure.</p> <p>### Patches</p> <p>JupyterLab [`v4.5.7`](https://github.com/jupyterlab/jupyterlab/releases/tag/v4.5.7) contains the patch.</p> <p>Users of applications that depend on JupyterLab, such as Notebook v7+, should update `jupyterlab` package too.</p> <p>### Workarounds</p> <p>Switch to read-only extension manager by adding the following command line option:</p> <p>```bash --LabApp.extension_manager=readonly ```</p> <p>or the following traitlet:</p> <p>```…</p> <p><strong>Affected:</strong> Homebrew: jupyterlab</p> <p>The allow-list of extensions that can be installed from PyPI Extension Manager (`allowed_extensions_uris`) is not correctly enforced by JupyterLab prior to 4.5.7. The PyPI Extension Manager was not contained to packages listed on the default PyPI index.</p> <p>This has security implications for deployments that: - have allow-listed specific extensions with aim to prevent users from installing packages - have the kernel and terminals disabled or delegated to remote hosts (thus no access to install packages in the single-user server environment) - have multi-tenant deployments that is not configured for untrusted users (as per documented on JupyterHub https://jupyterhub.readthedocs.io/en/5.2.1/explanation/websecurity.html) - have the (default) PyPI Extension Manager enabled</p> <p>### Impact</p> <p>An authenticated attacker - such as a student in a shared JupyterHub environment or a user in a multi-tenant JupyterLab deployment - can escalate their privileges. This might allow for data exfiltration, lateral movement within the network, and persistent compromise of the server infrastructure.</p> <p>### Patches</p> <p>JupyterLab [`v4.5.7`](https://github.com/jupyterlab/jupyterlab/releases/tag/v4.5.7) contains the patch.</p> <p>Users of applications that depend on JupyterLab, such as Notebook v7+, should update `jupyterlab` package too.</p> <p>### Workarounds</p> <p>Switch to read-only extension manager by adding the following command line option:</p> <p>```bash --LabApp.extension_manager=readonly ```</p> <p>or the following traitlet:</p> <p>```…</p> https://cve.radiocsirt.org/vuln/brew-jupyterlab-cve-2026-42266 https://cve.radiocsirt.org/vuln/cve-2026-42266 <p><strong>Affected:</strong> jupyterlab, Red Hat Migration Toolkit for Applications 8.2, Red Hat OpenShift AI 3.4, Red Hat OpenShift AI (RHOAI)</p> <p>JupyterLab is an extensible environment for interactive and reproducible computing, based on the Jupyter Notebook Architecture. From 4.0.0 to 4.5.6, the allow-list of extensions that can be installed from PyPI Extension Manager (allowed_extensions_uris) is not correctly enforced by JupyterLab. The PyPI Extension Manager was not contained to packages listed on the default PyPI index. This vulnerability is fixed in 4.5.7.</p> <p><strong>Affected:</strong> jupyterlab, Red Hat Migration Toolkit for Applications 8.2, Red Hat OpenShift AI 3.4, Red Hat OpenShift AI (RHOAI)</p> <p>JupyterLab is an extensible environment for interactive and reproducible computing, based on the Jupyter Notebook Architecture. From 4.0.0 to 4.5.6, the allow-list of extensions that can be installed from PyPI Extension Manager (allowed_extensions_uris) is not correctly enforced by JupyterLab. The PyPI Extension Manager was not contained to packages listed on the default PyPI index. This vulnerability is fixed in 4.5.7.</p> https://cve.radiocsirt.org/vuln/cve-2026-42266 https://cve.radiocsirt.org/vuln/ghsa-37w4-hwhx-4rc4 <p><strong>Affected:</strong> PyPI: jupyterlab</p> <p>The allow-list of extensions that can be installed from PyPI Extension Manager (`allowed_extensions_uris`) is not correctly enforced by JupyterLab prior to 4.5.7. The PyPI Extension Manager was not contained to packages listed on the default PyPI index.</p> <p>This has security implications for deployments that: - have allow-listed specific extensions with aim to prevent users from installing packages - have the kernel and terminals disabled or delegated to remote hosts (thus no access to install packages in the single-user server environment) - have multi-tenant deployments that is not configured for untrusted users (as per documented on JupyterHub https://jupyterhub.readthedocs.io/en/5.2.1/explanation/websecurity.html) - have the (default) PyPI Extension Manager enabled</p> <p>### Impact</p> <p>An authenticated attacker - such as a student in a shared JupyterHub environment or a user in a multi-tenant JupyterLab deployment - can escalate their privileges. This might allow for data exfiltration, lateral movement within the network, and persistent compromise of the server infrastructure.</p> <p>### Patches</p> <p>JupyterLab [`v4.5.7`](https://github.com/jupyterlab/jupyterlab/releases/tag/v4.5.7) contains the patch.</p> <p>Users of applications that depend on JupyterLab, such as Notebook v7+, should update `jupyterlab` package too.</p> <p>### Workarounds</p> <p>Switch to read-only extension manager by adding the following command line option:</p> <p>```bash --LabApp.extension_manager=readonly ```</p> <p>or the following traitlet:</p> <p>```…</p> <p><strong>Affected:</strong> PyPI: jupyterlab</p> <p>The allow-list of extensions that can be installed from PyPI Extension Manager (`allowed_extensions_uris`) is not correctly enforced by JupyterLab prior to 4.5.7. The PyPI Extension Manager was not contained to packages listed on the default PyPI index.</p> <p>This has security implications for deployments that: - have allow-listed specific extensions with aim to prevent users from installing packages - have the kernel and terminals disabled or delegated to remote hosts (thus no access to install packages in the single-user server environment) - have multi-tenant deployments that is not configured for untrusted users (as per documented on JupyterHub https://jupyterhub.readthedocs.io/en/5.2.1/explanation/websecurity.html) - have the (default) PyPI Extension Manager enabled</p> <p>### Impact</p> <p>An authenticated attacker - such as a student in a shared JupyterHub environment or a user in a multi-tenant JupyterLab deployment - can escalate their privileges. This might allow for data exfiltration, lateral movement within the network, and persistent compromise of the server infrastructure.</p> <p>### Patches</p> <p>JupyterLab [`v4.5.7`](https://github.com/jupyterlab/jupyterlab/releases/tag/v4.5.7) contains the patch.</p> <p>Users of applications that depend on JupyterLab, such as Notebook v7+, should update `jupyterlab` package too.</p> <p>### Workarounds</p> <p>Switch to read-only extension manager by adding the following command line option:</p> <p>```bash --LabApp.extension_manager=readonly ```</p> <p>or the following traitlet:</p> <p>```…</p> https://cve.radiocsirt.org/vuln/ghsa-37w4-hwhx-4rc4