Threat database

virtualenv is a tool for creating isolated virtual python environments. From 21.14.9 until 21.14.13, the bash bin/activate script can copy an attacker-controlled --prompt value into PS1 without escaping dollar signs or backticks when both promptvars and POSIX mode are disabled during activation. Re-enabling promptvars, running set -o posix, or starting an interactive child bash that inherits the exported PS1 can then expand command substitution in the stored VIRTUAL_ENV_PROMPT value and execute commands as the user who activates the environment. This issue is fixed in version 21.14.13.

### 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: ```console $ 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. Without `PROMPT_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 loads [`lib/theme-and-appearance.zsh`](https://github.com/ohmyzsh/ohmyzsh/blob/4d4cfc287e9d887b81242c0e431b5f49f9cec5c1/lib/theme-and-appearance.zsh#L5) 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. ### Patches 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 when `PROMPT_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 ### Workarounds Set `VIRTUAL_ENV_DISABLE_PROMPT=1` before you source `activate`, which leaves `PS1` alone, or run `unsetopt 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 `ViaTemplateActivator.instantiate_template` replaces the placeholders in an activation template one key at a time, each across the whole text. When a value that it already substituted and quoted contains the name of a later placeholder, the later pass rewrites that name inside the quoted literal. The inserted value brings its own quotes, which close the outer literal, and the rest of the path runs as code when a user activates the environment. `__VIRTUAL_NAME__` holds the environment's directory name, so a destination such as `A__VIRTUAL_NAME__B/x'$(touch PWNED)'y` is enough. In the default `activate` for bash, the `VIRTUAL_ENV` line renders as: ```sh VIRTUAL_ENV='/tmp/t/A'x'"'"'$(touch PWNED)'"'"'y'B/x'"'"'$(touch PWNED)'"'"'y' ``` Sourcing that script runs `touch PWNED`. The same payload in a path without the placeholder name runs nothing. `activate.fish` runs the command the same way, and the reporter also showed Python code execution through `activate.xsh` and `bin/activate_this.py`. In `activate.csh`, a directory named after a prompt display placeholder, such as `__VIRTUAL_PROMPT_DISPLAY_TCSH__`, breaks the script with `Unmatched '''`. No change to `quote()` can stop this, because the rewrite happens after `quote()` ran; it defeats `shlex.quote` and `repr()` alike. An attacker needs to influence the destination path or `--prompt`: a CI job or wrapper tool that builds the path from a branch or project name, or a directory in a cloned repository or unpacked archive. The bug affects versions 20.26.6 through 21.14.1. Version 20.26.6 first quoted template values (#2768) and introduced the per-key loop. ### Patches Fixed in 21.14.2. Activation scripts now keep a placeholder name in the environment's path or prompt as plain text, and activating the example above runs nothing. Fix: https://github.com/pypa/virtualenv/commit/602b26623a724827ff171bf11fef4ad186d01f74 ### Workarounds Do not create an environment whose path or `--prompt` contains a placeholder name such as `__VIRTUAL_NAME__`, `__VIRTUAL_ENV__` or `__VIRTUAL_PROMPT__`, and inspect the generated activation script before you source one you did not create. ### Credits Kevin Stubbings (@Kwstubbs) of GitHub Security Lab reported this issue.

### Impact `FishActivator` defines no `quote()`, so it inherits `ViaTemplateActivator.quote`, which returns `shlex.quote(string)`. That function follows POSIX `sh` rules, where a backslash inside single quotes stays a literal character. fish reads `\'` inside single quotes as an escaped quote and `\\` as an escaped backslash. A value with a backslash before a quote therefore ends the literal somewhere other than where `shlex.quote` put the end, and fish expands the command substitution that follows. The environment path reaches `set -gx VIRTUAL_ENV`, and `--prompt` or `VIRTUALENV_PROMPT` reaches `set -gx VIRTUAL_ENV_PROMPT`. For `--prompt "x\'\$(touch PWNED)'\'"`, the generated `activate.fish` contains: ```fish set -gx VIRTUAL_ENV_PROMPT 'x\'"'"'$(touch PWNED)'"'"'\'"'"'' ``` `source bin/activate.fish` runs `touch PWNED`, and fish prints no error. The same payload as a directory name runs through `VIRTUAL_ENV`. `--prompt .` takes the current directory's name, so running virtualenv inside a directory someone else named is enough. Without the backslash the payload runs nothing, and under bash it runs nothing either. virtualenv generates `activate.fish` by default. 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. The bug affects every release up to 21.14.1 that ships `activate.fish`. The GHSA-p58f-9548-mpm2 fix in 21.7.13 moved the placeholders outside their quotes but kept `shlex.quote`. ### Patches Fixed in 21.14.2. `activate.fish` now escapes backslashes and single quotes the way fish reads them, so the example above runs nothing and shows the prompt as given. Fix: https://github.com/pypa/virtualenv/commit/3bddeaf8d02c3ee7f576503efb082f8f494cfcab ### Workarounds Do not create an environment whose path or prompt contains a backslash, and inspect `activate.fish` before you source one you did not create. ### Credits Kevin Stubbings (@Kwstubbs) of GitHub Security Lab reported this issue.

### 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 ```console $ 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 - [x] 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.

## Summary The deletion error handler obtains permission bits with lstat() but applies them through chmod(), which follows symlinks. On an eligible unlink failure this can change permissions outside the destination. Anthropic's OSS Scanner reported this as `ANT-2026-UK90QC27` in `virtualenv-20261015-005`, received on 15 October 2026. ## Affected area Permission recovery after a filesystem deletion error. ## Attacker-controlled input A deletion must fail on a symbolic-link entry and enter the permission-recovery branch. The invoking user must have permission to change the target mode. This is conditional error handling, not the normal successful unlink path. ## Affected code The relevant 21.14.8 source is in [safe_delete()](https://github.com/pypa/virtualenv/blob/a795ab116356afde11039cf2763d77e8a06da738/src/virtualenv/util/path/_sync.py). ## Mechanism `safe_delete()` asks `shutil.rmtree()` to retry a failed removal after adding owner-write permission. Its error handler calls `os.lstat(path)` for mode bits but `os.chmod(path, ...)` to apply them. For a symlink, `lstat` reads the link's mode while `chmod` follows the link. A link inside a read-only directory can therefore cause the target's mode to become `0777` before the retry fails. The target must be owned by the invoking user and initially not writable by that user; root does not reach this failure path. ## Reproduction and evidence The scanner packed a project containing a mode-`0555` `venv/bin/python/` directory and a symlink inside it pointing to the user's mode-`0400` `keys/deploy.pem`. An unprivileged user unpacked it and ran both plain `virtualenv venv` and `virtualenv --clear venv`. Both commands exited with `PermissionError` naming the directory inside `venv`, while the key's mode changed from `0400` to `0777`. A control archive with a writable directory completed normally and left the key at `0400`. The read-only mode survives `tar` or `cp -a`; a normal git clone does not preserve this setup. This changes permissions; it does not read the target or complete the virtualenv operation. Another account can use the widened mode only if it can traverse the target's parent directories. The scanner dates the active error handler to #3222, first released in 21.7.5. [PR #3427](https://github.com/pypa/virtualenv/pull/3427) avoids POSIX mode changes on deletion failure and handles Windows read-only entries without following reparse points. ## Attack sequence ```mermaid sequenceDiagram participant A as Prepared read-only venv tree participant V as safe_delete error handler participant L as Symlink in venv participant K as User's 0400 key A->>V: virtualenv venv or --clear venv V->>L: unlink fails in 0555 directory V->>L: lstat returns link mode 0777 V->>L: chmod follows symlink L->>K: target mode becomes 0777 V-->>A: retry fails with PermissionError Note over K: Other accounts can use new mode if parent paths are traversable ``` ## Reproducer files The following files are from the scanner report for `ANT-2026-UK90QC27`. They were tested against commit `a857a7823c73` in the scanner image. The `repro` entrypoint expects companion files under `/tmp/repro.d`; cases that change user IDs need a disposable root-capable container. The last output line is `BUG` when the reported behavior occurs. These files are included as evidence and were not rerun for this advisory update. **`repro`** ```text #!/usr/bin/env python3 import os import stat import subprocess import sys import tempfile from pathlib import Path NOBODY = 65534 work = Path(tempfile.mkdtemp(prefix="repro-safe-delete-")) os.chmod(work, 0o755) os.chown(work, NOBODY, NOBODY) # the attacker's project archive (venv/bin/python read-only), and the same archive with that folder writable make_archive = [sys.executable, "/tmp/repro.d/make_project_archive.py"] subprocess.run([*make_archive, work / "read-only.tar", "555"], check=True) subprocess.run([*make_archive, work / "writable.tar", "755"], check=True) subprocess.run(["tar", "-tvf", work / "read-only.tar"], check=True) # from here on an ordinary user: root's unlink never fails, so safe_delete's error handler would never run os.setgroups([]) os.setgid(NOBODY) os.setuid(NOBODY) os.umask(0o022) def unpack_next_to_key_and_run_virtualenv(label, home_name, archive_name, *options): home = work / home_name archive = work / archive_name key = home / "keys" / "deploy.pem" key.parent.mkdir(parents=True) key.write_text("PRIVATE KEY\n") key.chmod(0o400) subprocess.run(["tar", "-xf", archive], cwd=home, check=True) mode_before = stat.S_IMODE(key.stat().st_mode) command = ["virtualenv", "--no-periodic-update", "-q", *options, "venv"] # HOME is where virtualenv keeps its app-data; nobody's own, /nonexistent, cannot hold it result = subprocess.run( command, cwd=home / "proj", env={**os.environ, "HOME": str(home)}, stdout=subprocess.PIPE,

CVE-2026-113723 is an OS command injection vulnerability in pypa virtualenv prior to version 21.14.9. The issue arises because caller-supplied prompt text can be interpreted as executable syntax in the bash activation prompt. Exploitation requires an attacker to control the value passed to virtualenv and a user to activate the environment and view the prompt. This vulnerability is fixed in version 21.14.9.

virtualenv is a tool for creating isolated virtual python environments. Prior to 21.14.9, virtualenv's ScriptMakerCustom and pip pass an incompletely quoted interpreter path to distlib ScriptMaker when generating POSIX console scripts. When the path contains a space or produces a shebang longer than 127 bytes, distlib emits a /bin/sh wrapper whose double-quoted interpreter path still expands command substitutions and backticks. An attacker who influences the environment destination can therefore execute commands with the user's privileges when the user later runs a generated launcher; environment creation and activation do not trigger the command. Existing launchers are not repaired by upgrading virtualenv alone and must be regenerated, while a later independent pip installation or upgrade can reintroduce an affected launcher because pip's vendored distlib is unchanged. The virtualenv fix is released in version 21.14.9.

CVE-2026-113721 is a vulnerability in pypa virtualenv prior to version 21.14.9 involving improper link resolution before file access. It allows a local attacker with limited privileges to cause environment creation to overwrite or create files outside the intended directory by exploiting dangling symbolic or hard links during activation content generation and configuration file writing.

virtualenv is a tool for creating isolated virtual python environments. Prior to 21.14.9, the app-data copy seeder uses shutil.copy() to copy cached package files into later environments, causing cached source modes to override the current run's umask. A cache populated under a permissive umask can therefore produce files writable by another local account in a later traversable environment, allowing package code such as pip/__init__.py to be modified and executed by the environment owner. The attacker cannot force the earlier umask, and a private destination parent prevents access. This issue is fixed in version 21.14.9.

virtualenv is a tool for creating isolated virtual python environments. Prior to 21.14.9, the stdlib venv creator reads generated pyvenv.cfg with str.splitlines() and merges parsed keys over virtualenv's selected configuration. An untrusted caller who influences the destination pathname can include a line-boundary character such as U+2028 to inject keys including home and include-system-site-packages, causing path data to change configuration structure before final output. Setting include-system-site-packages to true weakens environment isolation, while an altered home can change which standard-library files the interpreter loads if the attacker also controls that location. The builtin creator does not use this readback path. This issue is fixed in version 21.14.9.

CVE-2026-113719 is a path traversal vulnerability in pypa virtualenv versions prior to 21.14.9. It occurs during environment creation when existing package metadata is reused, allowing deletion of files outside the intended environment directory if the invoking user has sufficient deletion permissions. The issue is fixed in version 21.14.9.

CVE-2026-113718 is a code injection vulnerability in pypa virtualenv versions prior to 21.14.9. It arises from improper handling of non-ASCII prompt or destination data in the POSIX xonsh activation script, where UTF-8 encoded data is written using repr() into activate.xsh. Under legacy multibyte codecs like GBK or Big5, this can allow an attacker to manipulate the script to execute arbitrary code when sourced. The issue is fixed in version 21.14.9.

virtualenv is a tool for creating isolated virtual python environments. Prior to 21.14.9, PipInvoke.get_pip_install_cmd() handles --seeder pip --download by calling get_wheel(download=False) and then allowing pip to consult the configured index, bypassing virtualenv's download_wheel() and verify_wheel_digest() path. When virtualenv's default-index PyPI digest comparison remains enabled, an index candidate matching the bundled package and version can therefore be selected without comparison to PyPI SHA-256 metadata. Explicit custom-index settings already opt out of that comparison and remain outside this verification-bypass claim; the demonstrated configuration used a non-PyPI index while leaving the index environment variables unset so the comparison policy remained active. This condition does not independently defeat TLS or establish control of the index response. This issue is fixed in version 21.14.9.

## Summary The builtin creator accepts existing directory symlinks through ensure_dir() and writes environment files through those directories. This permits writes outside the requested destination. Anthropic's OSS Scanner reported this as `ANT-2026-MUFJEG11` in `virtualenv-20261015-005`, received on 15 October 2026. ## Affected area Directory preparation before environment files are created. ## Attacker-controlled input Another account must be able to prepare linked entries below the chosen destination before creation. The invoking user must have access to the linked destination. This does not require write access to the target itself under the other account. ## Affected code The relevant 21.14.8 source is in [builtin creator](https://github.com/pypa/virtualenv/blob/a795ab116356afde11039cf2763d77e8a06da738/src/virtualenv/create/via_global_ref/builtin/via_global_self_do.py), [ensure_dir()](https://github.com/pypa/virtualenv/blob/a795ab116356afde11039cf2763d77e8a06da738/src/virtualenv/util/path/_sync.py). ## Mechanism The builtin creator calls `ensure_dir()` for `bin`, `lib`, and package directories. `ensure_dir()` accepts an existing symlink to a directory because `exists()` follows it. Interpreter creation, seed installation, and activation-script generation then write through that parent link. A final-file check cannot prevent a write through a linked parent. `--clear` removes the planted tree first; ordinary creation over a prepared destination reaches it. ## Reproduction and evidence The scanner's project tree contains `venv/bin -> ../../.local/bin` and a `.pth` file in the environment's package tree. With the user's initially empty `~/.local/bin` first on `PATH`, `virtualenv venv` exited successfully and wrote `python*`, `pip*`, and `activate*` into `~/.local/bin`. The marker was absent immediately after creation; a later `pip --version` on the user's `PATH` loaded the seeded environment and the planted `.pth` code wrote the marker. A second case began with the `bin` link resolving inside the environment; replacement of a planted package link during seeding changed where it resolved, and writes again reached `~/.local/bin`. The attacker must prepare entries in an existing destination. The `.pth` content is already attacker-controlled and would run if the user used that environment directly; the added effect is creation-time writing or replacement outside the requested tree and an executable on the user's `PATH` pointing at it. The scanner traces this default builtin path to 20.0.0b1. [PR #3429](https://github.com/pypa/virtualenv/pull/3429) replaces linked directory components before creation. Concurrent parent replacement remains a separate case. ## Attack sequence ```mermaid sequenceDiagram participant A as Prepared destination participant V as Builtin creator participant L as venv/bin symlink participant H as ~/.local/bin participant U as User A->>L: point to ../../.local/bin V->>L: ensure_dir accepts existing directory link V->>H: write python, pip and activate files through link V-->>U: creation reports success U->>H: run pip found on PATH H->>A: interpreter loads planted .pth A-->>U: marker created ``` ## Reproducer files The following files are from the scanner report for `ANT-2026-MUFJEG11`. They were tested against commit `a857a7823c73` in the scanner image. The `repro` entrypoint expects companion files under `/tmp/repro.d`; cases that change user IDs need a disposable root-capable container. The last output line is `BUG` when the reported behavior occurs. These files are included as evidence and were not rerun for this advisory update. **`repro`** ```text #!/usr/bin/env python3 import os import shutil import subprocess import sys from pathlib import Path WORK = Path("/tmp/planted-bin-link") shutil.rmtree(WORK, ignore_errors=True) def user_creates_venv_in_checkout_then_runs_pip(home, make_checkout): local_bin = home / ".local/bin" user_env = {"HOME": str(home), "PATH": f"{local_bin}:{os.environ['PATH']}"} local_bin_before = set(os.listdir(local_bin)) payload_marker = home / "PWNED" # the attacker's checkout arrives at ~/project subprocess.run([sys.executable, f"/tmp/repro.d/{make_checkout}", home / "project"], check=True) venv = home / "project/venv" print(f"CONTROL venv/bin before the run resolves to {os.path.realpath(venv / 'bin')}") # default options; the flag only keeps the run off the network subprocess.run(["virtualenv", "--no-periodic-update", "--quiet", "venv"], cwd=home / "project", env=user_env, check=True) written = sorted(set(os.listdir(local_bin)) - local_bin_before) payload_ran_at_creation = payload_marker.exists() print(f"OBSERVED venv/bin after the run resolves to {os.path.realpath(venv / 'bin')}") print(f"OBSERVED virtualenv wrote to {local_bin}: {written}") print(f"OBSERVED ~/PWNED exists after virtualenv: {payload_ran_at_creation}") # lat

virtualenv is a tool for creating isolated virtual python environments. Prior to 21.14.9, download_wheel() writes package-index downloads directly into the reusable wheel/house cache before selecting a verification target from pip's textual Saved output. With default-index digest comparison enabled, a controlled package index can inject a misleading Saved line through a discarded link's data-requires-python attribute; this forged-line variant also requires knowledge of an absolute path to the genuine bundled wheel. The wrong path can then be hashed, while a digest mismatch leaves the rejected archive in the cache for later selection without verification. A separate rejected-cache-file variant requires control over downloaded data or archive selection but not the forged-line prerequisites. Explicit custom-index exceptions are outside the promised PyPI comparison, and the issue does not independently bypass TLS or establish control of default PyPI. This issue is fixed in version 21.14.9.

A vulnerability in pypa virtualenv versions 21.14.8 and 21.14.9 allows insecure handling of temporary files during environment creation. The app-data seeder can leave an environment linked to temporary package files that are deleted after creation, but environment-variable and configuration-file forms of symlink_app_data can enable this insecure state even when the command-line flag is disabled. This causes the environment to depend on a cache pathname no longer controlled by its owner. The issue is fixed in version 21.14.10.

CVE-2026-102937 is an OS command injection vulnerability in pypa virtualenv versions prior to 21.7.12. The issue arises because BatchActivator.quote() returns prompt text unchanged before it is inserted into a Windows cmd.exe set command. An attacker who can influence the --prompt, VIRTUALENV_PROMPT, or related configuration can inject a double quote to break out of the intended assignment and execute arbitrary commands when the user activates the virtual environment. This vulnerability is fixed in version 21.7.12.

`download_wheel()` runs `pip download` and hands the result straight to the seeder, with nothing checking the bytes it gets back. The embedded pip and setuptools wheels carry a `BUNDLE_SHA256` that virtualenv checks on every load, but a wheel fetched over the network for the periodic-update feature or the `--download` flag had no equivalent verification. A compromised index, a stale mirror, or a MITM'd download (when TLS is intercepted, e.g. via a misconfigured or malicious CA) could substitute a different wheel under the same distribution/version/filename, and virtualenv would cache and seed it into every environment created afterward with no warning. Fixed by computing the downloaded wheel's sha256 and comparing it against the digest PyPI's public JSON API reports for that exact release, independent of which index actually served the file. The check is skipped, not treated as failure, when a custom index (`PIP_INDEX_URL`, `PIP_EXTRA_INDEX_URL`, `PIP_INDEX`) is configured, since a private index can legitimately serve a different, intentionally rebuilt wheel. Fix: https://github.com/pypa/virtualenv/pull/3251

### Impact The generated `activate` (bash/zsh) and `activate.fish` scripts interpolate a `shlex.quote`-ed value into a position that quotes it a second time. The extra quotes terminate the quoted run early and leave part of the value parsed as shell code, so a path containing shell metacharacters runs commands when a user sources the activation script. `activate` is affected through the virtual environment's own path, on the branch that reports a relocated environment: ```sh echo "Virtual environment directory __VIRTUAL_ENV__ does not exist!" >&2 ``` For a destination named `x'$(id)'y`, `shlex.quote` emits `'x'"'"'$(id)'"'"'y'`. The inner `"` closes the enclosing double quote and `$(id)` is left unquoted. Backtick and `;` payloads reach the same result. This branch runs whenever the recorded path is absent, which is the normal case for a virtual environment copied or distributed to another machine. `activate.fish` is affected through the interpreter's Tcl/Tk library paths: ```fish set -gx TCL_LIBRARY '__TCL_LIBRARY__' ``` `shlex.quote` already returns `'/tcl/(cmd)/lib'`, so the rendered line is `''/tcl/(cmd)/lib''`. fish concatenates the adjacent quoted runs and expands the `(cmd)` left between them. The same doubling also splits a path containing a space into two list elements, corrupting `TCL_LIBRARY` and `TK_LIBRARY`. This is the same defect class as GHSA-x78j-v8h9-3j2q, which covered `activate.bat`. ### Patches Fixed in 21.7.13 by moving the placeholders outside the surrounding quotes, so each value keeps only the quoting `shlex.quote` applied. Fix: https://github.com/pypa/virtualenv/pull/3252 ### Workarounds Avoid creating or distributing virtual environments whose path contains `'`, `` ` ``, `$`, `;`, `(` or `)`, and inspect the generated activation script before sourcing one you did not create.