chore(deps): update dependency virtualenv to v21 [security] by renovate[bot] · Pull Request #188 · andreoliwa/python-cdown

renovate · 2025-01-14T01:44:07Z

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package	Change	Age	Confidence
virtualenv (changelog)	`==20.23.1` → `==21.7.13`

virtualenv allows command injection through activation scripts for a virtual environment

CVE-2024-53899 / GHSA-rqc4-2hc7-8c8v

More information

Details

virtualenv before 20.26.6 allows command injection through the activation scripts for a virtual environment. Magic template strings are not quoted correctly when replacing. NOTE: this is not the same as CVE-2024-9287.

Severity

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

References

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

virtualenv Has TOCTOU Vulnerabilities in Directory Creation

CVE-2026-22702 / GHSA-597g-3phw-6986

More information

Details

Impact

TOCTOU (Time-of-Check-Time-of-Use) vulnerabilities in virtualenv allow local attackers to perform symlink-based attacks on directory creation operations. An attacker with local access can exploit a race condition between directory existence checks and creation to redirect virtualenv's app_data and lock file operations to attacker-controlled locations.

Affected versions: All versions up to and including 20.36.1

Affected users: Any user running virtualenv on multi-user systems where untrusted local users have filesystem access to shared temporary directories or where VIRTUALENV_OVERRIDE_APP_DATA points to a user-writable location.

Attack scenarios:

Cache poisoning: Attacker corrupts wheels or Python metadata in the cache
Information disclosure: Attacker reads sensitive cached data or metadata
Lock bypass: Attacker controls lock file semantics to cause concurrent access violations
Denial of service: Lock starvation preventing virtualenv operations

Patches

The vulnerability has been patched by replacing check-then-act patterns with atomic os.makedirs(..., exist_ok=True) operations.

Fixed in: PR #3013

Versions with the fix: 20.36.2 and later

Users should upgrade to version 20.36.2 or later.

Workarounds

If you cannot upgrade immediately:

Ensure VIRTUALENV_OVERRIDE_APP_DATA points to a directory owned by the current user with restricted permissions (mode 0700)
Avoid running virtualenv in shared temporary directories where other users have write access
Use separate user accounts for different projects to isolate app_data directories

References

GitHub PR: https://github.com/pypa/virtualenv/pull/3013
Vulnerability reported by: @tsigouris007
CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization (TOCTOU)
CWE-59: Improper Link Resolution Before File Access

Severity

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

References

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

virtualenv: Downloaded seed wheels (pip/setuptools) are not integrity-checked before use

CVE-2026-102930 / GHSA-94p9-xgh2-xp45

More information

Details

download_wheel() runs pip download and hands the result straight to the seeder, with nothing checking the bytes it gets back. The embedded pip and setuptools wheels carry a BUNDLE_SHA256 that virtualenv checks on every load, but a wheel fetched over the network for the periodic-update feature or the --download flag had no equivalent verification.

A compromised index, a stale mirror, or a MITM'd download (when TLS is intercepted, e.g. via a misconfigured or malicious CA) could substitute a different wheel under the same distribution/version/filename, and virtualenv would cache and seed it into every environment created afterward with no warning.

Fixed by computing the downloaded wheel's sha256 and comparing it against the digest PyPI's public JSON API reports for that exact release, independent of which index actually served the file. The check is skipped, not treated as failure, when a custom index (PIP_INDEX_URL, PIP_EXTRA_INDEX_URL, PIP_INDEX) is configured, since a private index can legitimately serve a different, intentionally rebuilt wheel. Fix: https://github.com/pypa/virtualenv/pull/3251

Severity

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

References

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

virtualenv writes prompt values into pyvenv.cfg without sanitizing line boundaries, allowing configuration injection

CVE-2026-102938 / GHSA-9h9j-4vrj-gf7g

More information

Details

Summary

pyvenv.cfg is a line-based format with no escape syntax. PyEnvCfg.write() wrote values verbatim, while PyEnvCfg._read_values() parses the file with str.splitlines(). A value containing a line boundary therefore became additional configuration lines, and because reading is last-wins, the injected keys replaced any key written earlier in the file.

Impact

The prompt value is the reachable input: it is set by --prompt, by the VIRTUALENV_PROMPT environment variable, or from the config file, and write() emits prompt before home. A crafted prompt can therefore set home in the generated pyvenv.cfg:

$ virtualenv --prompt $'x"\nhome = /attacker/path\nprompt = "z' venv
$ grep '^home' venv/pyvenv.cfg
home = /attacker/path

home is what tooling reads to locate the base interpreter, so a consumer that trusts it can be pointed elsewhere. implementation, version_info, version, executable, command and virtualenv are also written before prompt and can be replaced the same way.

This requires the prompt to come from somewhere other than the person running the command, for example a CI job templating a branch name into it, tooling deriving an environment name from user-supplied data, or an inherited VIRTUALENV_PROMPT. Where the operator supplies the prompt directly they already control the command line, and the effect is corruption rather than privilege gain: the value is truncated at the boundary and read back with a dangling quote.

Details

The boundary set is the one str.splitlines() recognizes, which is wider than \n: \r, \v, \f, the file, group and record separators, U+0085, U+2028 and U+2029 were all written through unchanged and all split the line when read back.

Patches

PyEnvCfg.write() now collapses those boundaries to spaces as it serializes each line, so it cannot emit a structurally invalid file regardless of what a caller places in content.

Workarounds

Do not pass externally influenced data as the virtualenv prompt. Strip line boundaries from any value before using it as --prompt or VIRTUALENV_PROMPT.

Severity

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

References

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

virtualenv: Command injection via --prompt in activate.bat (batch activator)

CVE-2026-102937 / GHSA-x78j-v8h9-3j2q

More information

Details

BatchActivator.quote() returned its input unchanged, the only activator with no escaping at all. --prompt, the VIRTUALENV_PROMPT environment variable, and the config file all set the prompt, and activate.bat writes it straight into @set "VAR=value". A prompt containing a double quote closes that string early, and whatever follows runs as live cmd.exe syntax:

$ virtualenv --prompt 'x" & calc & "' venv
$ venv\Scripts\activate.bat

runs calc the moment someone activates the environment. Confirmed on a real Windows runner. Anyone who templates a prompt from untrusted input (a CI job using a branch name, a wrapper script deriving an environment name from user input) hands an attacker code execution in the shell of anyone who activates the resulting venv on Windows.

Fixed in 21.7.12 by escaping the characters cmd.exe treats as live syntax inside this construct. Fix: https://github.com/pypa/virtualenv/pull/3250

Severity

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

References

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

virtualenv bash and fish activation scripts execute commands embedded in paths

CVE-2026-102925 / GHSA-p58f-9548-mpm2

More information

Details

Impact

The generated activate (bash/zsh) and activate.fish scripts interpolate a shlex.quote-ed value into a position that quotes it a second time. The extra quotes terminate the quoted run early and leave part of the value parsed as shell code, so a path containing shell metacharacters runs commands when a user sources the activation script.

activate is affected through the virtual environment's own path, on the branch that reports a relocated environment:

echo "Virtual environment directory __VIRTUAL_ENV__ does not exist!" >&2

For a destination named x'$(id)'y, shlex.quote emits 'x'"'"'$(id)'"'"'y'. The inner " closes the enclosing double quote and $(id) is left unquoted. Backtick and ; payloads reach the same result. This branch runs whenever the recorded path is absent, which is the normal case for a virtual environment copied or distributed to another machine.

activate.fish is affected through the interpreter's Tcl/Tk library paths:

set -gx TCL_LIBRARY '__TCL_LIBRARY__'

shlex.quote already returns '/tcl/(cmd)/lib', so the rendered line is ''/tcl/(cmd)/lib''. fish concatenates the adjacent quoted runs and expands the (cmd) left between them. The same doubling also splits a path containing a space into two list elements, corrupting TCL_LIBRARY and TK_LIBRARY.

This is the same defect class as GHSA-x78j-v8h9-3j2q, which covered activate.bat.

Patches

Fixed in 21.7.13 by moving the placeholders outside the surrounding quotes, so each value keeps only the quoting shlex.quote applied. Fix: https://github.com/pypa/virtualenv/pull/3252

Workarounds

Avoid creating or distributing virtual environments whose path contains ', `, $, ;, ( or ), and inspect the generated activation script before sourcing one you did not create.

Severity

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

References

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

Release Notes

pypa/virtualenv (virtualenv)

Conversation

renovate Bot commented Jan 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

virtualenv allows command injection through activation scripts for a virtual environment

Details

Severity

References

virtualenv Has TOCTOU Vulnerabilities in Directory Creation

Details

Impact

Patches

Workarounds

References

Severity

References

virtualenv: Downloaded seed wheels (pip/setuptools) are not integrity-checked before use

Details

Severity

References

virtualenv writes prompt values into pyvenv.cfg without sanitizing line boundaries, allowing configuration injection

Details

Summary

Impact

Details

Patches

Workarounds

Severity

References

virtualenv: Command injection via --prompt in activate.bat (batch activator)

Details

Severity

References

virtualenv bash and fish activation scripts execute commands embedded in paths

Details

Impact

Patches

Workarounds

Severity

References

Release Notes

What's Changed

What's Changed

What's Changed

What's Changed

New Contributors

What's Changed

What's Changed

What's Changed

What's Changed

What's Changed

New Contributors

What's Changed

What's Changed

New Contributors

What's Changed

What's Changed

What's Changed

What's Changed

What's Changed

What's Changed

What's Changed

What's Changed

What's Changed

New Contributors

What's Changed

What's Changed

What's Changed

New Contributors

What's Changed

What's Changed

What's Changed

What's Changed

New Contributors

What's Changed

What's Changed

What's Changed

New Contributors

What's Changed

What's Changed

What's Changed

renovate Bot commented Jan 14, 2025 •

edited

Loading