virtualenv CVE-2026-113715

Exploitation requires all of: (1) the virtualenv stdlib 'venv' creator being selected (--creator venv), which is NOT virtualenv's default builtin creator; (2) an untrusted caller able to influence the destination pathname passed to virtualenv; and (3) injection of a line-boundary character (e.g., U+2028, U+2029, newline, NEL, form-feed) into that path to smuggle keys such as 'include-system-site-packages' or 'home' into pyvenv.cfg. For the more serious 'home' impact (changing which standard-library files the interpreter loads), the attacker must ADDITIONALLY control the filesystem location referenced by the injected home value. Limiting factors: local attack vector, high complexity, the non-default creator requirement, and dependence on an application that feeds untrusted data into the environment destination path - vendor affected versions are all releases prior to 21.14.9.

This is a low-priority, defense-in-depth issue rather than an urgent threat. The vendor-supplied CVSS 4.0 vector (CVSS:4.0/AV:L/AC:H/AT:P/PR:N/UI:P/VC:L/VI:L/VA:L) scores only 2.0, and every signal reinforces that: the attack is local (AV:L), high-complexity (AC:H), carries an explicit attack requirement (AT:P), needs passive user interaction (UI:P), and yields only Low confidentiality/integrity/availability impact with no scope change to subsequent systems. The PR:N rating indicates no authentication is required of the attacker, but exploitation hinges on the attacker being able to influence the destination pathname passed to virtualenv - a constrained position, not open remote access. No EPSS score was provided in the input, so exploitation probability cannot be quantified here. There is no CISA KEV listing and no public exploit was supplied (the GitHub source evidence is the fix PR #3426, not weaponized exploit code), so this is no public exploit identified at time of analysis. The signals are internally consistent - a genuinely low real-world risk - and the only caveat is the missing EPSS datapoint. Note also that the vulnerable code path is the non-default stdlib 'venv' creator; the default builtin creator is unaffected, further narrowing exposure.

An application or script builds virtualenv environments using the stdlib venv creator and derives the destination path from untrusted input (e.g., a user-supplied project name). An attacker supplies a path containing a line-boundary character such as U+2028 followed by 'include-system-site-packages = true' or a crafted 'home' key, which virtualenv's str.splitlines() readback parses and merges into pyvenv.cfg, silently weakening environment isolation. No public proof-of-concept exploit is known; the behavior is documented only by the vendor fix.