CVE-2026-113718 in virtualenv
Summary
by MITRE • 10/20/2026
virtualenv is a tool for creating isolated virtual python environments. Prior to 21.14.9, POSIX xonsh activation quote() uses repr() to write printable non-ASCII prompt or destination data into UTF-8 activate.xsh, while xonsh can read that script using $XONSH_ENCODING. Under a legacy multibyte codec such as GBK or Big5, a UTF-8 trail byte can consume the backslash before an adjacent quote, allowing the literal to close and attacker-influenced statements to execute when the user sources the generated script. 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 critical code injection flaw rooted in improper handling of character encoding during the generation of activation scripts for xonsh shells on POSIX systems. Virtualenv is widely used by developers and operations teams to create isolated Python environments, ensuring dependency isolation across projects. When activating an environment using the xonsh shell, virtualenv generates a script named activate.xsh that configures various environment variables, including those controlling the command prompt and destination paths. The core technical flaw lies in how these non-ASCII characters are encoded within this generated script file. Specifically, the activation logic utilizes Python's repr() function to escape special characters such as quotes before writing them into the UTF-8 formatted activate.xsh file. While this approach is generally safe under standard ASCII or pure UTF-8 contexts, it fails when interpreted by a xonsh shell configured with legacy multibyte encodings like GBK or Big5 via the $XONSH_ENCODING variable.
The operational mechanism of this vulnerability exploits the interaction between Python's repr() output and the parsing behavior of legacy multi-byte character sets. In UTF-8, certain bytes are designated as continuation bytes that must follow a leading byte to form a valid multibyte character. However, in encodings like GBK or Big5, specific byte sequences can be interpreted differently than their UTF-8 counterparts. An attacker who controls the content of the virtual environment's prompt or destination path can inject a sequence where a trailing byte from one encoded character coincidentally matches the backslash escape character used by repr(). When xonsh reads the activate.xsh file using its configured legacy encoding, it interprets this specific byte as part of a multibyte character rather than an escape delimiter. Consequently, the preceding backslash is consumed or neutralized in the parsing process, effectively removing the escaping mechanism that was intended to protect against command injection. This allows any subsequent quote characters in the prompt or path data to break out of their string literals and execute arbitrary commands within the user's shell session upon sourcing the script.
The impact of this vulnerability is significant for users who rely on xonsh as their primary interactive shell, particularly those working with internationalized software development environments where non-ASCII characters are common in file paths or project names. If an attacker can influence the creation of a virtual environment—such as through a malicious package installation that sets specific metadata, or by tricking a user into creating an environment with controlled path structures—they could achieve remote code execution when the victim activates that environment. This bypasses standard shell protections because the injection occurs during the initialization phase before any interactive input is processed. The flaw highlights the dangers of assuming universal compatibility between Python's internal string representations and external shell interpreters, especially when dealing with legacy encodings that have different byte-level interpretations than UTF-8.
To mitigate this risk, organizations must ensure that all instances of virtualenv are upgraded to version 21.14.9 or later, where the encoding handling logic has been corrected to prevent these escape sequence manipulations. For environments unable to upgrade immediately, administrators should enforce strict policies regarding the use of xonsh with legacy encodings and avoid sourcing activation scripts from untrusted sources. Additionally, developers using virtualenv in automated pipelines should validate that environment paths do not contain complex non-ASCII sequences that could trigger this edge case until patches are applied. This vulnerability is categorized under CWE-78 Improper Neutralization of Special Elements used in an OS Command, commonly known as OS Command Injection, and aligns with ATT&CK technique T1059 which covers command and script interpretation vulnerabilities. The fix ensures that special characters are handled safely regardless of the encoding context, preserving the integrity of shell activation processes across diverse internationalized computing environments.