virtualenv bash activate runs commands from an environment name with a backslash before $GHSA-vxj4-q4g9-crj7
HIGHFix: pypa/virtualenv@c3104e0GHSA-vxj4-q4g9-crj7 is a high-severity (CVSS 7.8) OS Command Injection vulnerability in virtualenv. A fix is available for virtualenv — see the affected versions and patch details below.
Exploitation Status
No confirmed exploitation observed yet
- A successful exploit gives an attacker total control of the affected component, not partial access.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-vxj4-q4g9-crj7.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
GHSA-vxj4-q4g9-crj7 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 394,803 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
virtualenvReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
Summary
The bash activate script escapes the environment name for only one of the two passes bash makes over PS1, so a
backslash in the name undoes the escaping and a name containing \$(...) runs as commands in the user's shell each
time bash draws the prompt.
Affected area
src/virtualenv/activation/bash/activate.sh, the block that prepends the environment name to PS1.
Attacker-controlled input
The environment name: the environment directory's name, or the --prompt or VIRTUALENV_PROMPT value. An attacker
needs to influence it, for example through a CI job or wrapper tool that passes a branch, project or job name through,
or a directory in a cloned repository or unpacked archive. --prompt . takes the current directory's name.
Details
bash handles PS1 in two passes each time it draws the prompt: it first decodes backslash prompt escapes, turning \\
into \ and \$ into $ (or # for root), and then runs parameter expansion, command substitution and arithmetic
expansion on the result. Since 21.13.0 the script escapes backslashes, dollar signs and backticks in the name, but only
for the second pass, so the decode pass strips the escaping that a backslash in the name precedes. Releases before
21.13.0 do not escape the name at all. A bash running as root decodes \$ to #, so the payload shows the wrong text
there but runs nothing. zsh does no decode pass and is not affected.
Proof of concept
$ virtualenv --prompt 'a\$(touch PWNED)' env
$ bash --norc --noprofile -c 'source env/bin/activate; printf "%s" "${PS1@P}"'
$ ls PWNED
PWNED
Impact
Arbitrary command execution in the shell of a user who sources the activate script of an environment whose name an
attacker influenced, with that user's privileges, once per prompt draw.
Versions tested
21.14.6 with bash 5.2.15 on Debian bookworm, as an unprivileged user and as root.
Known mitigation
Set VIRTUAL_ENV_DISABLE_PROMPT=1 before you source activate, which leaves PS1 alone, or run shopt -u promptvars
if your prompt does not need expansion. Check the name of an environment you did not create before you source its
activate.
Latest release
- The problem reproduces on the latest virtualenv release.
21.14.6
Patches
Fixed in 21.14.7. Under bash, activate now escapes backslashes, dollar signs and backticks for both passes, so the
example above runs nothing and the prompt shows the name as given. zsh keeps the single escaping it needs.
Fix: https://github.com/pypa/virtualenv/commit/c3104e02474b652832a9bbaae79f6e1696296932
Credits
Found while running the virtualenv test suite as root inside the Anthropic OSS Scanner build image.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | virtualenv | all versions | 21.14.7pip install --upgrade 'virtualenv==21.14.7' |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for virtualenv, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update virtualenv to 21.14.7 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-vxj4-q4g9-crj7 is resolved across your whole dependency graph.
Workarounds
Stop passing untrusted input into the interpreter or shell: call the affected binary with an argument array rather than a composed command string, reject anything outside a strict allowlist of expected values, and run the component under an account that cannot reach beyond the work it legitimately does.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
--- CME Mitigation Guidance (2026-10-20) --- Disclaimer: The following mitigation solutions are provided as a courtesy, pending the application of an official patch. This content was generated utilizing AI tools in conjunction with data from https://cmetaxonomy.org. Customers are advised to independently evaluate and test these temporary mitigations within their own infrastructure. The highest-value action is to sanitize virtual environment names and eliminate unescaped shell variable interpolation in bash prompt configuration scripts: upgrade to virtualenv 21.14.7 (or the fixed Uv/Rhoai/Odh Kserve Agent Rhel/Rhoai/Odh Kserve Controller Rhel/Rhoai/Odh Kserve Router Rhel/Rhoai/Odh Kserve…Source: Red Hat security advisory for GHSA-vxj4-q4g9-crj7 (CC BY 4.0)
Frequently Asked Questions
Is GHSA-vxj4-q4g9-crj7 in your dependencies?
Find it across PyPI, including transitive dependencies.