CVE-2026-113718

What it actually does

In virtualenv versions before 21.14.9, the POSIX xonsh activation script generator uses repr() on non-ASCII prompt or path data when writing UTF-8 activate.xsh. When xonsh later interprets the script under a legacy multibyte codec such as GBK or Big5, a UTF-8 continuation byte can consume the backslash preceding a quote, prematurely terminating the string literal and allowing attacker-controlled statements to be injected into the sourced script.

Why it matters to the business

An attacker who can influence the virtualenv prompt or destination path can achieve arbitrary code execution in the context of any user who later sources the generated activation script, potentially leading to compromise of development or build environments.

How an attack unfolds

An attacker crafts a virtualenv creation command that embeds a malicious non-ASCII sequence in the prompt or destination path. When virtualenv generates activate.xsh it writes the data via repr(), producing a UTF-8 literal. A victim running xonsh with a legacy multibyte encoding enabled sources the script; the encoding misinterprets the byte sequence, closes the string early, and executes the injected commands.

How to fix it

Upgrade virtualenv to version 21.14.9 or later on all systems that generate xonsh activation scripts. After upgrade, regenerate any existing activate.xsh files. If immediate upgrade is impossible, avoid sourcing activation scripts under legacy multibyte encodings or switch to a different shell activation mechanism.

How to confirm the fix worked

Confirm virtualenv --version reports 21.14.9 or newer. Inspect generated activate.xsh files for absence of raw repr() output containing non-ASCII data and verify that sourcing the script under GBK/Big5 does not execute unexpected commands.

Typical attack path

1. Attacker supplies a malicious non-ASCII prompt or path to virtualenv create
2. virtualenv writes activate.xsh using repr() on the supplied data
3. Victim configures xonsh with a legacy multibyte encoding and sources the generated script
4. Encoding quirk consumes the backslash, closes the literal, and runs attacker statements

How to detect it

Review shell history and virtualenv creation logs for commands that include non-ASCII characters in prompts or paths. Examine generated activate.xsh files for suspicious repr()-style strings containing high-bit bytes. Check xonsh configuration for legacy multibyte encoding settings.

What your security team should do

• Immediately upgrade all virtualenv installations to 21.14.9 or newer
• Scan build and CI systems for use of xonsh activation scripts and regenerate them after patching
• Add virtualenv version checks to dependency scanning and container base images
• Monitor for any internal use of legacy multibyte encodings with xonsh