GHSA-x78j-v8h9-3j2q: OS Command Injection
BatchActivator.quote() returned its input unchanged, the only activator with no escaping at all. --prompt, the VIRTUALENVPROMPT environment variable, and the config file all set the prompt, and activate.bat writes it straight into @set "VAR=value". A prompt containing a double quote closes that string early, and whatever follows runs as live cmd.exe syntax:
console $ virtualenv --prompt 'x" & calc & "' venv $ venv\Scripts\activate.bat
runs calc the moment someone activates the environment. Confirmed on a real Windows runner. Anyone who templates a prompt from untrusted input (a CI job using a branch name, a wrapper script deriving an environment name from user input) hands an attacker code execution in the shell of anyone who activates the resulting venv on Windows.
Fixed in 21.7.12 by escaping the characters cmd.exe treats as live syntax inside this construct. Fix: https://github.com/pypa/virtualenv/pull/3250
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/virtualenvto a version that resolves this vulnerability.Fixed in 21.7.12 - Upgrade
Upgrade
virtualenvto a version that resolves this vulnerability.Fixed in 21.7.12
Event History
Frequently Asked Questions
Who is exposed to this issue?
Windows users who activate a virtual environment are exposed when its prompt was created from untrusted input. This is especially relevant to CI jobs, wrapper scripts, or templating workflows that derive the prompt or environment name from attacker-controlled values such as branch names.
What must an attacker control to trigger code execution?
The attacker needs to influence the virtualenv prompt through --prompt, the VIRTUALENV_PROMPT environment variable, or the configuration file. A double quote in the resulting prompt can terminate the @set assignment in activate.bat and cause following text to be interpreted as cmd.exe syntax when the environment is activated.
Is code execution triggered when the environment is created?
No. The supplied example shows execution occurring when a user runs venv\Scripts\activate.bat, so the payload runs in the shell of the person who activates the affected environment.
Which version contains the fix?
The issue was fixed in virtualenv 21.7.12. The fix escapes characters that cmd.exe treats as live syntax in this prompt-setting construct.