virtualenv EUVD-2026-89465

Requires that the prompt value - supplied via the --prompt CLI flag, the VIRTUALENV_PROMPT environment variable, or virtualenv configuration input - originate from outside the operator's trust boundary (e.g. an automated venv-creation pipeline that derives the prompt from an untrusted project name, CI/CD variable, or shared config file). The attacker must be able to embed a character that str.splitlines() treats as a line boundary (\n, \r, \v, \f, \x1c-\x1e, \x85, U+2028, or U+2029) plus an injected key such as 'home'. Limiting factors: exploitation is local (AV:L), needs a virtualenv run (user interaction), and only affects trust when prompt input is externally influenced - a directly operator-supplied prompt merely corrupts the operator's own environment. Fixed configurations running virtualenv 21.7.11+ are not exploitable.

This is a genuine but conditional integrity flaw, not a high-severity emergency. The vendor CVSS 4.0 vector (5.8, AV:L/AC:L/AT:P/PR:N/UI:P) is internally consistent with the description: exploitation is local, requires a passive attack precondition (AT:P) and user interaction (UI:P - an operator running virtualenv), and the dominant impact is integrity (VI:H) because injecting a duplicate 'home' key steers consumers to an attacker-selected base interpreter. There is no EPSS score, no CISA KEV listing, and no public weaponized exploit - the PR adds an atheris fuzz harness and hypothesis property tests, which demonstrate the injection invariant but are defensive test tooling, not exploit code, so this is 'no public exploit identified at time of analysis.' The critical caveat, stated explicitly by the advisory, is that the security impact only materializes when prompt input crosses the operator's trust boundary (e.g. a prompt derived from an untrusted project name, CI variable, or shared config); a directly-typed prompt merely corrupts the operator's own environment and is self-inflicted. The 'Information Disclosure' tag conflicts with the actual VI:H/VC:L profile - the real risk is configuration injection leading to interpreter substitution (integrity/code-path control), not data leakage. Net: real priority for automated/multi-tenant virtualenv pipelines where prompts come from untrusted sources; low real risk for ordinary interactive developer use despite virtualenv's ubiquity.

An automation system (e.g. CI or a hosting platform) creates virtual environments and derives the --prompt or VIRTUALENV_PROMPT value from attacker-controlled data such as a repository name or user-supplied config. The attacker embeds a line boundary (newline, carriage return, or a Unicode separator like U+2028) followed by 'home = /attacker/path' in that value, so virtualenv writes a pyvenv.cfg whose reader parses the injected line and, because the last duplicate key wins, overrides the real 'home' with an attacker-selected base interpreter. No public exploit code exists, and exploitation is local with required user interaction.