CVE-2026-113718: virtualenv: Xonsh activation literals depend on the script decoding codec
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 $XONSHENCODING. 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
virtualenvto a version that resolves this vulnerability.Fixed in 21.14.9
Event History
Frequently Asked Questions
Who is exposed to this issue?
Users who source a generated POSIX xonsh activation script are exposed when xonsh reads the UTF-8 activate.xsh file using a legacy multibyte encoding such as GBK or Big5. The issue involves non-ASCII prompt or destination data written into that script.
What must an attacker control to execute code?
An attacker must be able to influence data that virtualenv writes into the generated xonsh activation script, specifically data that can interact with the encoding mismatch and adjacent quote escaping. Exploitation also requires the user to source that generated script under the affected xonsh encoding conditions.
What should teams do to remediate the issue?
Upgrade virtualenv to version 21.14.9 or later, which fixes the issue. If an immediate upgrade is not possible, avoid sourcing generated xonsh activation scripts with legacy multibyte encodings such as GBK or Big5.