CVE-2026-113717 in virtualenv
Summary
by MITRE • 10/20/2026
virtualenv is a tool for creating isolated virtual python environments. Prior to 21.14.9, PipInvoke.get_pip_install_cmd() handles --seeder pip --download by calling get_wheel(download=False) and then allowing pip to consult the configured index, bypassing virtualenv's download_wheel() and verify_wheel_digest() path. When virtualenv's default-index PyPI digest comparison remains enabled, an index candidate matching the bundled package and version can therefore be selected without comparison to PyPI SHA-256 metadata. Explicit custom-index settings already opt out of that comparison and remain outside this verification-bypass claim; the demonstrated configuration used a non-PyPI index while leaving the index environment variables unset so the comparison policy remained active. This condition does not independently defeat TLS or establish control of the index response. This issue is fixed in version 21.14.9.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/20/2026
The vulnerability identified within virtualenv versions prior to 21.14.9 represents a significant integrity assurance failure rooted in how package installation commands are constructed and executed during environment initialization. Virtualenv relies on pip as its underlying package manager, but it implements additional security layers such as digest verification to ensure that downloaded packages match expected cryptographic hashes. The core flaw resides in the PipInvoke.get_pip_install_cmd() function when handling specific invocation patterns involving the --seeder flag combined with pip download operations. In this scenario, the tool invokes get_wheel(download=False) and subsequently allows pip to consult its configured package index directly. This execution path effectively bypasses virtualenv's internal verification mechanisms, specifically the verify_wheel_digest() method that is designed to compare downloaded artifacts against known good SHA-256 hashes stored in PyPI metadata or local bundles.
This architectural oversight creates a situation where an attacker controlling a malicious mirror or performing a man-in-the-middle attack on a non-TLS connection could substitute a compromised package for the legitimate one, provided it matches the requested name and version. Although virtualenv maintains default-index settings that enable PyPI digest comparison by design, this bypass allows index candidates to be selected without undergoing the rigorous SHA-256 verification process. The vulnerability is particularly insidious because it does not inherently defeat TLS encryption or provide direct control over the index response through protocol exploitation alone; rather, it exploits a logical gap in the tool's workflow that renders its integrity checks ineffective for specific installation paths. This means that even with secure transport protocols enabled, the authenticity of the package content cannot be guaranteed if this code path is triggered.
From an industry standards perspective, this vulnerability aligns closely with CWE-20 Improper Input Validation and CWE-345 Insufficient Verification of Data Authenticity. The failure to verify cryptographic hashes before installation constitutes a breakdown in data integrity checks, which are critical for supply chain security. In the context of the MITRE ATT&CK framework, this flaw facilitates Supply Chain Compromise techniques, specifically those involving software dependency manipulation or malicious package injection during automated build and deployment processes. Attackers could leverage this weakness to introduce backdoors, malware, or other malicious code into isolated Python environments under the false assumption that virtualenv's built-in protections are active.
The operational impact of this vulnerability is severe for development teams and CI/CD pipelines that rely on virtualenv to create reproducible and secure build environments. If a developer inadvertently triggers the affected code path while using a custom index or specific configuration variables, they may unknowingly install compromised dependencies. This risk persists even when environment variables are unset because the default policy remains active yet is circumvented by the flawed command construction logic. The issue highlights the dangers of delegating security-critical operations to external tools without ensuring that wrapper scripts enforce their own integrity checks consistently across all execution paths.
To mitigate this vulnerability, organizations must immediately upgrade virtualenv to version 21.14.9 or later, where the code path has been corrected to ensure digest verification is not bypassed during pip download operations. Until an upgrade can be performed, administrators should audit their automation scripts for usage patterns that invoke get_pip_install_cmd with --seeder and pip download flags, as these are the primary vectors for exploitation. Additionally, enforcing strict pinning of package versions in requirements files and utilizing private repositories with verified signatures can provide defense-in-depth measures. It is also advisable to review any custom index configurations to ensure they do not inadvertently trigger this bypass condition by leaving relevant environment variables unset while relying on default verification policies that are now known to be unreliable for specific command sequences.