virtualenv 21.14.3 High-Severity Command Injection in Zsh Activate Script

A high-severity command injection flaw in the virtualenv package allows arbitrary code execution in zsh shells. Security advisory GHSA-5vjq-rrrf-7h2q identifies the issue, CVE-2026-113726, as affecting versions up to 21.14.3, with a patch available in version 21.14.4.

What happened

The vulnerability exists because the bash activate script fails to escape special characters for zsh users. Since version 21.13.0, the script escapes backslashes and dollar signs only if the BASH_VERSION variable is set. Zsh shells do not have this variable, so they receive raw values. When the PROMPT_SUBST option is enabled, zsh executes parameter and command substitution on the PS1 variable each time it renders the prompt.

Why it matters

Environments created with names containing command syntax, such as $(...), will execute those commands in the user's shell. This affects any workflow where environment names are derived from external sources, such as CI job names, branch names, or directory names from cloned repositories. The flaw is particularly prevalent among oh-my-zsh users, as the framework enables PROMPT_SUBST by default during startup. Without this option, or when using bash, the shell treats the name as plain text and does not execute commands.

Next steps

• Update virtualenv to version 21.14.4 or later to apply the official patch.
• Audit CI pipelines and wrapper tools for untrusted input being passed to virtualenv prompts.
• Review zsh configurations to determine if PROMPT_SUBST is enabled by default in development environments.
• Check for any unexpected files or artifacts created in recently activated virtual environments.

Detection notes

Teams usually detect this activity by monitoring for anomalous command execution originating from shell prompt rendering. Security operations centres should check whether terminal sessions show repeated execution of commands tied to environment activation events. Look for unexpected file creation or network connections occurring immediately after a user sources an activate script.

Containment moves involve isolating affected development workstations and reviewing shell history for command substitution patterns in prompt variables. Analysts should verify if standard shell configurations have been modified to enable dangerous expansion features that allow arbitrary code execution through environment variable names.

What to do and how to stay safe: virtualenv

• Verify the installed version of virtualenv across all development and CI servers.
• Inspect shell configuration files for the PROMPT_SUBST setting in zsh environments.
• Monitor for successful activations of virtual environments with unusual or dynamic names.
• Once the vendor provides an update, deploy the patched version to all affected systems.

Step-by-step guide: Emergency Patching: How to Fix Critical Flaws Without Breaking Production

General security guidance from the Packet Tribune newsroom. It is not confirmed advice from the organisations named in this story.

Frequently asked questions

Which versions of virtualenv are vulnerable to this command injection?

Versions up to and including 21.14.3 are vulnerable, with the fix released in 21.14.4.

Does this vulnerability affect users of the bash shell?

No, bash does not execute the commands because it does not perform the same prompt expansion without explicit configuration.

How can an attacker exploit this vulnerability?

An attacker needs to influence the environment name or prompt, such as through a CI job name or a directory name in a cloned repository.