Summary
virtualenv bash activate runs commands from an environment name with a backslash before $
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
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 itsactivate.
Latest release
- The problem reproduces on the latest virtualenv release.
21.14.6
Credits
Found while running the virtualenv test suite as root inside the Anthropic OSS Scanner build image.
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.
Untrusted input reaches a shell command, allowing arbitrary commands to run on the host. Typical impact: code execution in the application's environment.
CVE-2026-113725 has a CVSS score of 7.8 (High). The vector is requires local access, no privileges required, and user interaction required. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (21.14.7); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
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
Frequently Asked Questions
- What is CVE-2026-113725? CVE-2026-113725 is a high-severity OS command injection vulnerability in virtualenv (pip), affecting versions <= 21.14.6. It is fixed in 21.14.7. Untrusted input reaches a shell command, allowing arbitrary commands to run on the host.
- How severe is CVE-2026-113725? CVE-2026-113725 has a CVSS score of 7.8 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of virtualenv are affected by CVE-2026-113725? virtualenv (pip) versions <= 21.14.6 is affected.
- Is there a fix for CVE-2026-113725? Yes. CVE-2026-113725 is fixed in 21.14.7. Upgrade to this version or later.
- Is CVE-2026-113725 exploitable, and should I be worried? Whether CVE-2026-113725 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-113725 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-113725? Upgrade
virtualenvto 21.14.7 or later.