Organisations urged to update virtualenv to fix high-severity bash command execution flaw
A flaw in virtualenv allows arbitrary command execution in bash when environment names contain backslashes; version 21.14.7 provides a fix for this high-severity issue.
Key points
- CVE-2026-113725 allows command execution via manipulated environment names in bash prompts.
- Virtualenv versions up to 21.14.6 are vulnerable; 21.14.7 resolves the issue.
- Zsh users are unaffected because the shell does not perform the problematic decode pass.
Virtualenv releases 21.14.7 addresses a high-severity vulnerability, CVE-2026-113725, that enables arbitrary command execution. The flaw exists in the bash activation script and affects installations running version 21.14.6 or earlier. Users who source the activation script for an environment with a malicious name face immediate risk. The patch corrects how the script handles special characters during prompt rendering. Teams managing Python development environments should prioritize updating to the patched version immediately to stop potential exploitation.
How it unfolded
- The vulnerability stems from how bash processes the PS1 prompt variable in two distinct passes.
- Virtualenv versions since 21.13.0 attempted to escape dangerous characters but only for the second pass.
- A backslash in the environment name undoes the escaping during the first decode pass.
- This allows payloads like `$(...)` to execute as commands every time the prompt draws.
Who is affected
The vulnerability impacts any system using virtualenv versions 21.14.6 or older with bash. The attacker must control or influence the environment name, such as through CI jobs, wrapper tools, or cloned repositories. The `--prompt` flag and `VIRTUALENV_PROMPT` variable are also attack vectors. Zsh is not affected because it does not perform the initial decode pass that strips the escaping. Root users see incorrect text but the payload does not run due to hash character substitution.
Our take on the response
The vendor has released version 21.14.7 to fix the issue. The advisory details that the flaw allows command execution with the user's privileges. Since the fix is available, the primary task is deployment. The vulnerability requires user interaction, specifically sourcing the activate script, which limits automated exploitation but keeps the risk high for development workflows. The known mitigation involves disabling the prompt, which reduces functionality but stops execution.
Who needs to act first
Teams usually prioritize systems exposed to untrusted code, such as CI runners or shared development servers. Check whether your environments pull names from external sources like branch names or archive contents. Test the update in a non-production environment first to ensure compatibility with your build pipelines. Back up your current virtual environment configurations before applying the patch. If you cannot update immediately, reduce exposure by disabling the prompt feature on affected systems. This prevents the malicious string from being processed by the shell during activation.
Background: Attack vectors
Attack vectors are the paths adversaries use to reach your data. They range from simple phishing emails to complex supply chain compromises. Defending against them requires mapping every entry point, validating inputs, and limiting what each component can do. You cannot stop all attacks, but you can make them costly and slow.
Read the full guide: Attack Vectors Explained: Mechanisms, Limits, and Defense Strategies
What to do and how to stay safe: virtualenv
- Update virtualenv to version 21.14.7 or later on all systems running bash.
- Audit CI/CD pipelines that generate environment names from user-controlled inputs.
- Set VIRTUAL_ENV_DISABLE_PROMPT=1 as a temporary mitigation if updating is delayed.
- Review logs for unexpected command executions in development shell sessions.
Step-by-step guide: Vulnerability Prioritization: How to Rank Risks Without Wasting Time
General security guidance from the Patch Observer newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
Does this vulnerability affect zsh users?
No, zsh is not affected because it does not perform the initial decode pass that allows the escaping to be stripped.
What is the highest vulnerable version of virtualenv?
Version 21.14.6 is the highest vulnerable version; 21.14.7 contains the fix.
Can root users be exploited by this flaw?
Root users are not executed against because bash decodes the dollar sign to a hash, preventing command substitution.
