CVE-2026-113721 in virtualenv
Summary
by MITRE • 10/20/2026
virtualenv is a tool for creating isolated virtual python environments. Prior to 21.14.9, ViaTemplateActivator._generate() removes an existing output only when Path.exists() is true, allowing a dangling symlink to survive and redirect generated activation content, while PyEnvCfg.write() opens pyvenv.cfg without first replacing an existing symbolic or hard link. Another local account that prepares final entries inside the destination can therefore cause environment creation to create or overwrite files outside the requested tree with constrained virtualenv-generated content and the invoking user's permissions. The destination parent must remain controlled by the environment owner during creation; concurrent parent-directory replacement is a separate concern. This issue is fixed in version 21.14.9.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/20/2026
The vulnerability identified in Python’s virtualenv library prior to version 21.14.9 represents a significant file system manipulation risk rooted in improper handling of symbolic links and hard links during the environment initialization process. Virtual environments are designed to provide isolated execution contexts for Python projects, ensuring that dependencies do not interfere with one another or the host system. However, the underlying implementation failed to adequately validate the integrity of destination paths before writing configuration files or generating activation scripts. This oversight allows an attacker who has local access and control over specific directories within the target path structure to manipulate how virtualenv writes data, potentially leading to unauthorized file modifications outside the intended sandboxed environment.
The technical flaw manifests in two distinct but related mechanisms within the library’s core modules. First, the ViaTemplateActivator._generate() method is responsible for creating activation scripts such as activate.bat or activate.ps1. In vulnerable versions, this function checks if an output path exists using Path.exists(). If a symbolic link pointing to a location outside the virtual environment tree already resides at that path, Path.exists() returns true because it follows the symlink and finds the target file. Consequently, the code proceeds to overwrite only the content of the linked file rather than removing the malicious link itself or ensuring the destination is a legitimate directory entry within the new environment. This results in the activation script being written into an arbitrary location controlled by the attacker, effectively redirecting the execution flow when users attempt to activate the virtual environment.
Secondly, the PyEnvCfg.write() method handles the creation of pyvenv.cfg, a critical configuration file that defines the home directory and other settings for the virtual environment. This function opens the target file for writing without first verifying whether an existing symbolic link or hard link occupies that path. If such a link exists, the write operation will overwrite the content pointed to by the link rather than creating a new file within the isolated tree. Since these operations are performed with the permissions of the invoking user, any local account can exploit this behavior if they have write access to parent directories leading up to or including parts of the destination path. This allows for arbitrary file overwrites on the host system, constrained only by the privileges of the user running virtualenv and their ability to place symlinks in accessible locations relative to the target environment directory.
The operational impact of this vulnerability is severe, particularly in shared development environments or continuous integration pipelines where multiple users or automated processes create virtual environments within common base directories. An attacker could craft a scenario where they pre-position symbolic links pointing to sensitive system files, configuration backups, or other critical resources. When another user runs virtualenv with the intention of creating an isolated environment at that location, the tool inadvertently corrupts or overwrites those external targets. This can lead to data loss, privilege escalation if the overwritten file is executed later by a higher-privileged process, or denial of service through corruption of essential system configurations. The issue highlights the danger of assuming directory structures are static and safe during dynamic environment creation processes.
To mitigate this risk, organizations must ensure that all instances of virtualenv are updated to version 21.14.9 or later, where these path validation checks have been strengthened to detect and reject symbolic links and hard links before performing write operations. In environments where upgrading is not immediately feasible, administrators should enforce strict directory permissions so that only trusted users can create directories in shared paths used for virtual environment generation. Additionally, adopting a policy of using unique, non-shared base directories for each project or user reduces the attack surface by preventing unauthorized actors from placing symlinks in relevant parent folders. Security teams should also audit CI/CD pipelines to ensure they do not rely on predictable directory structures that could be manipulated via race conditions or pre-existing link artifacts.
This vulnerability aligns with CWE-59, which describes Improper Link Resolution Before File Access, commonly known as a Time-of-check to Time-of-use (TOCTOU) issue involving symbolic links. The attack vector is classified under MITRE ATT&CK technique T1078, Valid Accounts, specifically focusing on local account manipulation and persistence through file system artifacts. By exploiting the lack of rigorous path validation during environment setup, attackers can achieve unauthorized access or modification of files outside their designated scope. Remediation requires both software updates to address the code-level flaws and operational changes to restrict directory write permissions in shared development spaces, thereby eliminating the prerequisite conditions for this exploitation chain.