CVE-2026-113713 in virtualenv
Summary
by MITRE • 10/20/2026
virtualenv is a tool for creating isolated virtual python environments. From 21.14.8 until 21.14.10, the app-data seeder can leave an environment linked to temporary package files that virtualenv deletes when creation finishes. The environment-variable and configuration-file forms of symlink_app_data can enable this state even though the command-line flag is disabled for temporary app-data. The resulting environment depends on a cache pathname that its owner no longer controls. This issue is fixed in version 21.14.10.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/20/2026
The vulnerability identified within virtualenv versions ranging from 21.14.8 to 21.14.10 represents a significant flaw in the lifecycle management of isolated Python environments, specifically concerning the handling of application data symlinks during the seeding process. Virtualenv is widely utilized by developers and automated systems to create self-contained Python execution contexts that prevent dependency conflicts across different projects or deployments. The core issue arises from an inconsistency in how the tool manages temporary files when creating these environments with linked application data, such as pip caches or user configuration directories. When virtualenv initializes a new environment using specific methods to link app-data rather than copying it, it relies on temporary storage locations that are intended for transient use during the setup phase.
The technical flaw manifests through an improper cleanup mechanism where the tool fails to properly detach the newly created environment from these temporary package files before deleting them. This behavior is triggered when users employ either the environment-variable form or the configuration-file form of the symlink_app_data setting. Notably, this vulnerability persists even if the command-line flag for enabling temporary app-data symlinks is explicitly disabled, indicating a logic error in how different input vectors are processed and validated within the application's initialization routine. Consequently, the resulting virtual environment retains hard links or symbolic references to files located in directories that virtualenv subsequently deletes upon completion of the creation process. This leaves the environment dependent on cache pathnames that no longer exist or are under the control of the original creator, effectively breaking the isolation guarantees provided by the tool.
From an operational impact perspective, this vulnerability can lead to immediate runtime failures for scripts and applications relying on the affected virtual environments. Developers may encounter import errors when attempting to use packages installed within these compromised environments because the underlying binary or data files have been removed from disk. In automated deployment pipelines where virtualenv is used programmatically, this could result in silent build failures or unpredictable behavior during subsequent execution phases. The issue undermines the reliability of development workflows and CI/CD processes that depend on consistent environment creation. Furthermore, if an attacker can influence the path structure or timing of these operations, there may be potential for race conditions or symlink attacks where malicious files are placed in the temporary directory before deletion occurs, although the primary impact described is functional instability due to missing dependencies.
This vulnerability aligns with CWE-506, which covers Embedded External Control of File Name or Path, as well as CWE-377, Insecure Temporary File Creation, given that the tool relies on insecure assumptions about file persistence in temporary directories. It also relates to ATT&CK technique T1499, Endpoint Denial of Service, if exploited to disrupt development workflows by rendering environments unusable. The root cause is a failure in state management where the transition from creation to finalization does not correctly update references or migrate data out of volatile storage areas.
To mitigate this risk, organizations and developers must upgrade virtualenv to version 21.14.10 or later immediately. This release corrects the logic errors that allow environments to remain linked to deleted temporary files. For teams unable to upgrade instantly, it is advisable to avoid using the environment-variable and configuration-file methods for enabling symlink_app_data until a patch is applied. Instead, relying on explicit command-line flags with caution or switching to alternative isolation tools like venv or conda may provide safer interim solutions. Regular auditing of dependency management scripts can also help detect environments created during this vulnerable window that might be prone to failure upon execution.