Impact When Jupyter Lab, jupyter-server-proxy and Dask distributed are all run together it is possible to craft a URL which will result in code being executed by Jupyter due to a cross-side-scripting (XSS) bug in the Dask dashboard.

It is possible for attackers to craft a phishing URL that assumes Jupyter Lab and Dask may be running on localhost and using default ports. If a user clicks on the malicious link it will open an error page in the Dask Dashboard via the Jupyter Lab proxy which will cause code to be executed by the default Jupyter Python kernel.

In order for a user to be impacted they must be running Jupyter Lab locally on the default port (with the jupyter-server-proxy) and a Dask distributed cluster on the default port. Then they would need to click the link which would execute the malicious code.

Patches This has been fixed in the 2026.1.1 release. All users should upgrade to this version.

Mitigations There are no known workarounds for this bug. The only complete solution is to upgrade to a newer release of Dask. However, there are a few things you could do to reduce your risk.

It is possible to avoid code execution via Jupyter by uninstalling the jupyter-server-proxy and accessing the Dask dashboard directly at it's URL. However, it is still possible for an attacker to craft a URL that executes JavaScript in the user's browser in the Dask dashboard. Which is still a moderate vulnerability. Therefore we recommend all users upgrade to the latest Dask release.

Another potential mitigation is to ensure both Jupyter and the Dask dashboard are running on non-standard ports. While this doesn't resolve the problem it reduces the chance of this being exploited. If an attacker knew which ports you were using they could still craft a malicious URL, but it would require a more targeted attack.

Anaconda3 macOS installers before 2024.06-1 contain a local privilege escalation vulnerability when installed outside the user's home directory. During installation, world-writable files are created and executed with root privileges. This allows a local low-privileged user to inject arbitrary commands, leading to code execution as the root user.

conda-smithy is a tool for combining a conda recipe with configurations to build using freely hosted CI services into a single repository. Prior to version 3.47.1, the travisencryptbinstartoken implementation in the conda-smithy package has been identified as vulnerable to an Oracle Padding Attack. This vulnerability results from the use of an outdated and insecure padding scheme during RSA encryption. A malicious actor with access to an oracle system can exploit this flaw by iteratively submitting modified ciphertexts and analyzing responses to infer the plaintext without possessing the private key. This issue has been patched in version 3.47.1.

Conda-build contains commands and tools to build conda packages. Prior to version 25.3.0, the pyproject.toml lists conda-index as a Python dependency. This package is not published in PyPI. An attacker could claim this namespace and upload arbitrary (malicious) code to the package, and then exploit pip install commands by injecting the malicious dependency in the solve. This issue has been fixed in version 25.3.0. A workaround involves using --no-deps for pip install-ing the project from the repository.

Conda-build contains commands and tools to build conda packages. Prior to version 25.4.0, the conda-build processing logic is vulnerable to path traversal (Tarslip) attacks due to improper sanitization of tar entry paths. Attackers can craft tar archives containing entries with directory traversal sequences to write files outside the intended extraction directory. This could lead to arbitrary file overwrites, privilege escalation, or code execution if sensitive locations are targeted. This issue has been patched in version 25.4.0.

Conda-build contains commands and tools to build conda packages. Prior to version 25.4.0, the conda-build recipe processing logic has been found to be vulnerable to arbitrary code execution due to unsafe evaluation of recipe selectors. Currently, conda-build uses the eval function to process embedded selectors in meta.yaml files. This approach evaluates user-defined expressions without proper sanitization, which allows arbitrary code to be executed during the build process. As a result, the integrity of the build environment is compromised, and unauthorized commands or file operations may be performed. The vulnerability stems from the inherent risk of using eval() on untrusted input in a context intended to control dynamic build configurations. By directly interpreting selector expressions, conda-build creates a potential execution pathway for malicious code, violating security assumptions. This issue has been patched in version 25.4.0.

Conda-build contains commands and tools to build conda packages. Prior to version 25.3.1, the writebuildscripts function in conda-build creates the temporary build script condabuild.sh with overly permissive file permissions (0o766), allowing write access to all users. Attackers with filesystem access can exploit a race condition to overwrite the script before execution, enabling arbitrary code execution under the victim's privileges. This risk is significant in shared environments, potentially leading to full system compromise. Even with non-static directory names, attackers can monitor parent directories for file creation events. The brief window between script creation (with insecure permissions) and execution allows rapid overwrites. Directory names can also be inferred via timestamps or logs, and automation enables exploitation even with semi-randomized paths by acting within milliseconds of detection. This issue has been patched in version 25.3.1. A workaround involves restricting condabuild.sh permissions from 0o766 to 0o700 (owner-only read/write/execute). Additionally, use atomic file creation (write to a temporary randomized filename and rename atomically) to minimize the race condition window.

Anaconda 3 2023.03-1-Linux allows local users to disrupt TLS certificate validation by modifying the cacert.pem file used by the installed pip program. This occurs because many files are installed as world-writable on Linux, ignoring umask, even when these files are installed as root. Miniconda is also affected.

Certain Anaconda3 2021.05 are affected by OS command injection. When a user installs Anaconda, an attacker can create a new file and write something in usercustomize.py. When the user opens the terminal or activates Anaconda, the command will be executed.

Anaconda Anaconda3 (Anaconda Distribution) through 2021.11.0.0 and Miniconda3 through 4.11.0.0 can create a world-writable directory under %PROGRAMDATA% and place that directory into the system PATH environment variable. Thus, for example, local users can gain privileges by placing a Trojan horse file into that directory. (This problem can only happen in a non-default installation. The person who installs the product must specify that it is being installed for all users. Also, the person who installs the product must specify that the system PATH should be changed.

An issue was discovered in Dask (aka python-dask) through 2021.09.1. Single machine Dask clusters started with dask.distributed.LocalCluster or dask.distributed.Client (which defaults to using LocalCluster) would mistakenly configure their respective Dask workers to listen on external interfaces (typically with a randomly selected high port) rather than only on localhost. A Dask cluster created using this method (when running on a machine that has an applicable port exposed) could be used by a sophisticated attacker to achieve remote code execution.