CVE-2026-113720 in virtualenv
Summary
by MITRE • 10/20/2026
virtualenv is a tool for creating isolated virtual python environments. Prior to 21.14.9, the app-data copy seeder uses shutil.copy() to copy cached package files into later environments, causing cached source modes to override the current run's umask. A cache populated under a permissive umask can therefore produce files writable by another local account in a later traversable environment, allowing package code such as pip/__init__.py to be modified and executed by the environment owner. The attacker cannot force the earlier umask, and a private destination parent prevents access. This issue is fixed in version 21.14.9.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/20/2026
The vulnerability identified within virtualenv versions prior to 21.14.9 stems from an improper handling of file permissions during the package seeding process. Virtualenv operates by creating isolated Python environments, and one of its mechanisms involves copying cached package files into these new environments using a copy seeder method known as app-data. This specific implementation relies on the standard library function shutil.copy() to transfer data. The critical technical flaw lies in how this function interacts with the operating system's file creation mask, or umask. When shutil.copy() is invoked without explicit permission adjustments, it inherits and applies the umask settings of the process that originally populated the cache rather than respecting the umask context of the current environment being created. This discrepancy creates a scenario where files are generated with permissions determined by an earlier, potentially more permissive execution context instead of the intended restrictive defaults for the new isolated environment.
The operational impact of this flaw is significant in multi-user systems or shared development environments. If a cache directory was populated under a permissive umask setting, such as one that allows group write access, all subsequent files copied from that cache into newly created virtual environments will retain those overly open permissions. Consequently, package files within the new environment may become writable by other local user accounts on the same system. This breaks the fundamental isolation guarantee provided by virtualenv. An attacker with a separate local account can exploit this misconfiguration to modify critical Python source code files located in the target environment's directory structure. Specifically, modules such as pip/_init_.py are prime targets because they are executed during package installation and management operations. By altering these files, an attacker can inject malicious logic that will be executed by the legitimate owner of the virtualenv when they perform standard tasks like installing new packages or updating existing ones.
This vulnerability aligns with CWE-732, which describes improper permission assignment for critical resources, as well as CWE-94, concerning code injection vulnerabilities resulting from insufficient control over input data that affects program flow. From a tactical perspective, this flaw facilitates privilege escalation through lateral movement within the same host system and supports persistence mechanisms if malicious scripts are embedded in widely used packages. It also relates to ATT&CK technique T1053, specifically scheduled tasks or cron jobs if combined with other vectors, but more directly it represents an opportunity for code execution via supply chain compromise at the local file level. The attacker does not need to force a specific umask on the victim's system; they merely need to ensure their own cache population occurs under permissive settings and wait for a target user to create a new environment that pulls from this shared or accessible cache location.
Mitigation strategies primarily involve upgrading virtualenv to version 21.14.9 or later, where the developers have addressed the permission handling logic to ensure consistent umask application regardless of the source cache's original state. In environments where immediate patching is not feasible, administrators should enforce strict umask policies across all user accounts to minimize the risk profile associated with shared caches. Additionally, restricting access to global package caches and ensuring that virtualenv directories are owned exclusively by their respective users can reduce the attack surface. Regular auditing of file permissions within development environments and monitoring for unexpected modifications to core Python library files in active projects serve as effective detection mechanisms for this type of exploitation attempt.