CVE-2026-113724 in virtualenv
Summary
by MITRE • 10/20/2026
virtualenv is a tool for creating isolated virtual python environments. Prior to 21.14.9, the safe_delete() deletion error handler responds to a failed removal by reading mode bits with os.lstat(path) and applying owner-write permission with os.chmod(path, ...), which follows a symlink. A planted link inside a read-only directory can therefore cause a victim-owned target outside the destination that is initially not writable by the invoking user to become broadly writable before the retry fails, provided that user owns the target and can change its mode. Another account can use the widened mode only if it can traverse the target's parent directories; root does not reach the demonstrated failure path, and the operation does not itself read the target. This issue is fixed in version 21.14.9.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/20/2026
The vulnerability identified in virtualenv prior to version 21.14.9 represents a classic Time-of-Check-to-Time-of-Use (TOCTOU) race condition rooted in improper handling of symbolic links during file system operations. Virtualenv is widely used by developers and automated systems to create isolated Python environments, making it a critical component in many software development pipelines. The specific flaw resides within the safe_delete error handler, which is designed to manage failures when attempting to remove files or directories. When an initial removal attempt fails due to permission restrictions, this handler attempts to rectify the situation by modifying file permissions to allow deletion. However, the implementation relies on os.lstat() followed by os.chmod(), a sequence that inadvertently follows symbolic links rather than operating strictly on the link itself. This behavior violates the principle of least privilege and safe path handling, as it allows an attacker who controls a symlink within a read-only directory to influence permissions on arbitrary files owned by the victim user elsewhere in the file system hierarchy.
From a technical perspective, the core issue is that os.chmod() operates on the target of a symbolic link if one exists at the specified path, rather than on the link itself. In this scenario, an attacker plants a symlink inside a directory where they have write access but no read or execute permissions for others, such as a sticky bit protected directory or simply a directory with restrictive modes that prevent direct file creation by other users. When virtualenv attempts to clean up its temporary environment and encounters a failure in deleting a path containing this planted link, the safe_delete handler invokes os.lstat() followed by os.chmod(). Because the path resolves through the symlink, chmod applies the owner-write permission bit to the target of that symlink. If the victim user owns this external file or directory and has the capability to change its mode, their permissions are inadvertently widened from read-only or restricted access to broadly writable. This escalation occurs before the deletion retry fails, leaving a window where the attacker can exploit the newly granted write permissions.
The operational impact of this vulnerability is significant for multi-user systems or shared hosting environments where multiple accounts interact with virtualenv instances. An attacker who can create symlinks in directories accessible by the victim process can escalate privileges to modify files owned by that user, provided they have traversal access to the parent directories of the target file. This effectively bypasses intended isolation boundaries and could lead to unauthorized modification of configuration files, source code, or other critical assets belonging to the victim. While root users are not affected because their operations do not trigger this specific failure path due to elevated privileges allowing direct removal without needing permission changes, regular users face a tangible risk of privilege escalation through file system manipulation. The vulnerability does not involve reading sensitive data from the target but focuses on altering its state, which can be leveraged for further attacks such as code injection or denial of service by corrupting essential files.
This flaw aligns with CWE-367: Time-of-check-Time-of-use (TOCTOU) Race Condition and CWE-22: Improper Limitation of a Pathname to a Restricted Directory, also known as Path Traversal. In the context of the MITRE ATT&CK framework, this behavior relates to techniques involving file system discovery and permission modification for privilege escalation or persistence establishment. The lack of atomic operations in checking permissions and applying changes creates a race condition that can be exploited if an attacker has control over directory contents within the scope of the virtualenv operation. Mitigation requires upgrading to version 21.14.9, where this logic has been corrected to prevent following symlinks during permission adjustments. Until such upgrades are applied in production environments, administrators should ensure strict isolation between user accounts and avoid running untrusted code or using shared directories with restrictive permissions for virtualenv operations. Additionally, employing security tools that monitor for unexpected changes in file modes across the system can help detect exploitation attempts of this nature.