CVE-2026-102925 in virtualenv
Summary
by MITRE • 09/30/2026
virtualenv is a tool for creating isolated virtual python environments. Prior to 21.7.13, the generated activate (bash and zsh) and activate.fish scripts place values already escaped by shlex.quote inside an additional quoted context. In the bash and zsh script, a crafted virtual environment path reaches __VIRTUAL_ENV__ when a relocated environment's recorded directory is absent; in the fish script, crafted Tcl or Tk library paths reach __TCL_LIBRARY__ or __TK_LIBRARY__. The surplus quotes can terminate the data-only quoted run and leave shell metacharacters parsed as commands when a user sources the activation script, allowing code execution with that user's privileges. This issue is fixed in version 21.7.13.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/30/2026
The vulnerability identified within virtualenv versions prior to 21.7.13 represents a critical shell injection flaw rooted in improper handling of string escaping and quoting contexts during the generation of activation scripts for bash, zsh, and fish shells. Virtualenv is widely used by developers to create isolated Python environments, ensuring that project dependencies do not conflict with one another or the system-wide Python installation. The core mechanism involves generating shell scripts that modify environment variables such as PATH, PYTHONHOME, and TCL_LIBRARY upon sourcing. These scripts are designed to be safe for execution in their respective shells, but a logic error in how paths containing special characters were processed led to a breakdown in this safety guarantee. Specifically, the tool was applying an additional layer of quoting around values that had already been escaped using shlex.quote, which is intended to make strings safe for shell interpretation by escaping all metacharacters and wrapping them in quotes if necessary.
In the bash and zsh activation scripts, the flaw manifests when a user attempts to source the activate script from within a relocated virtual environment where the originally recorded directory path no longer exists on the filesystem. Under these conditions, the variable _VIRTUAL_ENV_ is populated with a crafted path that contains shell metacharacters such as semicolons, ampersands, or backticks. Because the existing value was already escaped by shlex.quote, it typically includes surrounding quotes to ensure literal interpretation. However, virtualenv wrapped this already-quoted string in another set of double quotes without properly handling the internal escaping. This nesting causes the inner closing quote to terminate the outer data-only quoted context prematurely. Once the quoting is broken, any subsequent shell metacharacters present in the crafted path are no longer treated as literal characters but are instead parsed and executed by the shell interpreter.
A similar issue exists within the fish shell activation script, where crafted Tcl or Tk library paths can reach the _TCL_LIBRARY_ or _TK_LIBRARY_ environment variables. Fish shells have distinct parsing rules compared to POSIX-compliant shells like bash and zsh, yet the fundamental flaw remains consistent: the double-quoting of pre-escaped values allows for quote termination if the input string contains specific sequences that interact poorly with the shell's parser. When a user sources the activation script in this compromised state, the shell interprets the residual metacharacters as commands rather than data. This results in arbitrary code execution under the privileges of the current user who sourced the script. Since sourcing scripts is often an automated or semi-automated step in development workflows, users may inadvertently execute malicious payloads simply by opening a terminal and activating their virtual environment with a crafted path structure.
From a threat modeling perspective, this vulnerability aligns with CWE-78 Improper Neutralization of Special Elements used in an OS Command, commonly known as OS Command Injection. The attacker does not need to inject code directly into the application logic but rather manipulates the configuration or file system state (the virtual environment directory path) to trigger execution within a trusted script context. In terms of MITRE ATT&CK mapping, this behavior is consistent with techniques involving command and scripting interpreter abuse, specifically where an adversary leverages legitimate scripts for lateral movement or privilege escalation if higher privileges are involved in the sourcing process. The impact is significant because it allows remote code execution potential if combined with other vectors that allow attackers to control file paths on a target system, such as through symlink attacks or controlled directory creation in shared environments.
The operational impact of this vulnerability extends beyond simple script failure; it introduces a risk of unauthorized command execution during routine development activities. Developers who share virtual environment directories across systems or use automated tools that create and relocate environments are particularly at risk if they source activation scripts without verifying the integrity of the underlying paths. The flaw persists until version 21.7.13, which corrects the quoting logic to ensure that special characters in path names do not break out of their intended data context. To mitigate this issue immediately before upgrading, users should avoid sourcing activation scripts from virtual environments located in directories with untrusted or dynamically generated paths containing shell metacharacters. Additionally, organizations can implement static analysis tools to detect the use of vulnerable versions of virtualenv in CI/CD pipelines and enforce dependency updates through automated patching mechanisms. Upgrading to version 21.7.13 or later is the definitive remediation strategy, as it resolves the underlying parsing error by correctly handling nested quoting scenarios for all supported shell types.