virtualenv CVE-2026-102930

Exploitation requires all of: (1) the attacker occupies the wheel delivery path - a compromised package index, a stale/poisoned mirror, or an intercepted TLS connection to PyPI (AC:H/AT:P); (2) virtualenv fetches seed wheels via a periodic update or the --download option; (3) the environment uses the DEFAULT PyPI path - the digest check (and thus this fix) is intentionally skipped when PIP_INDEX_URL, PIP_EXTRA_INDEX_URL, or PIP_INDEX is set, and a pip.conf custom index is invisible to the check entirely; and (4) a user actually creates/seeds a virtual environment (UI:P). Limiting factors: affected virtualenv versions prior to 21.7.12, the need for an active MITM or index/mirror compromise, and required user action. Note that even after patching, custom-index configurations remain unverified by design.

This is a genuine supply-chain integrity flaw but not a top-tier emergency. The vendor CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:N/UI:P) shows the two features that temper the 7.7 score: AC:H and AT:P mean the attacker must already control the delivery path (compromise the index, poison a mirror, or actively MITM the TLS connection to PyPI), and UI:P means a user must actually create/seed a virtual environment. There is no EPSS score, no CISA KEV listing, and no public exploit identified at time of analysis, so this is a latent risk rather than one under active mass exploitation. The impact if the preconditions are met is severe (VC:H/VI:H/VA:H - attacker-controlled pip/setuptools wheels seeded into every subsequently created environment, i.e. code execution), which justifies treating it as a real priority for organizations that pull seed wheels over untrusted networks or through mirrors. Note the CWE and the vendor 'Information Disclosure' tag conflict: this is CWE-494 (download of code without integrity check) with integrity/availability impact, not an information-disclosure bug. The verification fix also only applies to the default PyPI path and is deliberately skipped for custom indexes, so environments using PIP_INDEX_URL/pip.conf remain unverified by design - a limitation defenders should understand.

An attacker who controls a corporate PyPI mirror, a poisoned package index, or a position to MITM the TLS connection substitutes a malicious pip or setuptools wheel that keeps the requested distribution name, version, and filename. When a developer or CI job runs virtualenv against the default PyPI index (periodic seed update or --download), the unverified wheel is cached and seeded into every new environment, executing attacker code. No public PoC is known, and the attack requires both an active man-in-the-middle/index-compromise position (AC:H/AT:P) and a user creating an environment (UI:P).