Summary
virtualenv activate runs commands from the environment name in zsh with PROMPT_SUBST
Workarounds
Set VIRTUAL_ENV_DISABLE_PROMPT=1 before you source activate, which leaves PS1 alone, or rununsetopt prompt_subst if your prompt does not need it. Check the name of an environment you did not create before you
source its activate.
Credits
Kaya Emre Arikan (@kemrec) reported this issue.
Impact
zsh users activate an environment with the bash activate script, which puts the environment name into PS1. Since
21.13.0 the script escapes backslashes, dollar signs and backticks in that name, but only when BASH_VERSION is set, so
zsh gets the raw value. With the PROMPT_SUBST option set, zsh runs parameter expansion, command substitution and
arithmetic expansion on PS1 each time it draws the prompt. A name that contains $(...), backticks or ${...} then
runs as commands in the user's shell, once per prompt.
The name comes from the environment directory, or from --prompt or VIRTUALENV_PROMPT. After you create an
environment with:
$ virtualenv 'x$(touch PWNED)y'
source 'x$(touch PWNED)y/bin/activate' in a zsh session with PROMPT_SUBST set creates PWNED, and the prompt shows(xy). Passing that value as --prompt to an environment with a plain name has the same effect. WithoutPROMPT_SUBST, zsh shows the name as text and runs nothing. bash runs nothing either.
A plain zsh starts with PROMPT_SUBST off. oh-my-zsh users have it on: oh-my-zsh loadslib/theme-and-appearance.zsh
at startup, and that file sets it. An attacker needs to influence the environment path or prompt: 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.
zsh also reads % in PS1 as a prompt escape, so a name with %n showed the user name in place of those characters,
though without running commands.
The bug is in releases up to and including 21.14.3. The payload runs on 20.26.6 and 21.14.3, and the reporter confirmed
21.9.1.
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-113726 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.4); 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.4. Under zsh, activate now escapes the name the way it does under bash and doubles%, so the example above runs nothing and the prompt shows the name as given. zsh gets the escaping even whenPROMPT_SUBST is off, because a user can set the option after activation; a name with a backslash, dollar sign or
backtick then shows the added backslashes.
Fix: https://github.com/pypa/virtualenv/commit/5b915367da82bd024b2a0d28d2f98007034b4aa2
Frequently Asked Questions
- What is CVE-2026-113726? CVE-2026-113726 is a high-severity OS command injection vulnerability in virtualenv (pip), affecting versions <= 21.14.3. It is fixed in 21.14.4. Untrusted input reaches a shell command, allowing arbitrary commands to run on the host.
- How severe is CVE-2026-113726? CVE-2026-113726 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-113726? virtualenv (pip) versions <= 21.14.3 is affected.
- Is there a fix for CVE-2026-113726? Yes. CVE-2026-113726 is fixed in 21.14.4. Upgrade to this version or later.
- Is CVE-2026-113726 exploitable, and should I be worried? Whether CVE-2026-113726 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-113726 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-113726? Upgrade
virtualenvto 21.14.4 or later.