CVE-2026-6357: 
Python vulnerability analysis and mitigation

CVE-2026-6357 is a moderate-severity vulnerability in pip (the Python package installer) classified as "Inclusion of Functionality from Untrusted Control Sphere" (CWE-829). In pip versions prior to 26.1, the self-update check functionality ran after installing wheel files, which caused pip to import well-known Python module names that had been intentionally deferred to improve CLI startup time. This timing window allowed a malicious wheel package to place code in locations that would be imported during pip's self-update check. The vulnerability was disclosed on April 27, 2026, and affects all pip versions before 26.1. It carries a CVSS v4 base score of 5.3 (Medium) (GitHub Advisory, oss-security).

The root cause is CWE-829 (Inclusion of Functionality from Untrusted Control Sphere): pip's self-update check deferred certain module imports to improve startup performance, but this deferral meant those imports occurred after wheel installation completed. A malicious wheel package could place Python modules at well-known import paths that pip would subsequently import during the self-update check, enabling code execution in the context of the pip process. Exploitation requires the attacker to have high privileges (e.g., ability to publish or supply a malicious wheel), specific environmental conditions (Attack Requirements: Present), and active user interaction — the victim must actually run pip install against the malicious package. The fix, implemented in pull request #13923, reorders the self-update check to run before wheels are installed, eliminating the import timing window (pip PR #13923, GitHub Advisory).

Successful exploitation could allow an attacker to execute arbitrary code with the privileges of the user running pip, impacting both confidentiality and integrity of the vulnerable system (CVSS v4: VC:High, VI:High, VA:None). There is no availability impact and no impact on subsequent systems. The practical risk is constrained by the requirement for high attacker privileges and active user interaction, but in CI/CD pipelines or automated environments where pip installs packages from potentially untrusted sources, the impact could extend to secrets exposure or supply chain compromise (GitHub Advisory, oss-security).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the time of disclosure. The EPSS score is approximately 0.012–0.017%, placing it in the 4th percentile for exploitation likelihood. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No threat actor attribution has been reported (GitHub Advisory).

1. Craft a malicious wheel package: The attacker creates a Python wheel (.whl) file that, upon installation, places a malicious Python module at a well-known import path (e.g., shadowing a module name that pip's self-update check imports).
2. Distribute the malicious wheel: The attacker must have high privileges to make the wheel available — for example, by publishing to a package index, performing a dependency confusion attack, or supplying the wheel directly in an environment where the victim will install it.
3. Victim installs the wheel: A user (or automated process) runs pip install <malicious-package> using a vulnerable pip version (< 26.1). pip installs the wheel files to disk.
4. pip runs self-update check: After installation, pip's self-update check triggers and imports the well-known Python module names that were deferred for startup performance. The malicious module placed by the wheel is imported instead of the legitimate one.
5. Arbitrary code execution: The attacker's code runs in the context of the pip process, with the privileges of the user who invoked pip, potentially enabling credential theft, file system access, or further lateral movement (pip PR #13923, GitHub Advisory).

• File System: Unexpected Python module files placed at well-known import paths within the Python environment's site-packages directory that shadow standard library or pip-internal module names; wheel installation artifacts from unrecognized or untrusted packages.
• Process: Unusual child processes or network connections spawned by the pip process immediately after a package installation completes (during the self-update check phase).
• Logs: pip installation logs showing packages installed from untrusted or unexpected sources; anomalous import errors or tracebacks in pip output referencing modules that should not be user-supplied.

Upgrade pip to version 26.1 or later, which reorders the self-update check to run before wheel installation, eliminating the import timing window (pip PR #13923, GitHub Advisory). As a temporary workaround, set the environment variable PIP_DISABLE_PIP_VERSION_CHECK=1 to disable the self-update check entirely, removing the vulnerable code path. Users should also carefully review the contents of all packages prior to installation, particularly from untrusted or third-party sources, and restrict pip installation privileges to necessary personnel. IBM has released updates for affected IBM App Connect Enterprise Certified Container products (IBM Advisory).

The vulnerability was disclosed via the Python Security Announce mailing list by Seth Larson on April 27, 2026, and forwarded to oss-security by Alan Coopersmith (oss-security). The pip maintainer community discussed the fix extensively in the pull request, with reviewers noting the historically tricky nature of self-update check changes and validating the fix against various upgrade/downgrade scenarios (pip PR #13923). Coverage appeared on InfoQ and Linux security news outlets, and the fix was highlighted in the pip 26.1 release blog post as a security fix (pip 26.1 blog). General community sentiment treated this as a moderate supply-chain hygiene issue rather than a critical emergency, given the high privilege requirements.