CVE-2026-6357

What it actually does

pip versions before 26.1 could run self-update check logic after installing a wheel. That logic imported well-known Python module names after the newly installed package was already present on disk, allowing a malicious or crafted wheel to influence what gets imported. If the imported module contains import-time side effects, code can execute in the context of the pip process. Because exploitation requires a user or automation to install an attacker-controlled wheel and typically depends on the privileges used to run pip, impact is highest where pip is executed as an administrator, root user, or privileged CI/CD account.

Why it matters to the business

An attacker who can get a developer, administrator, build worker, or automation pipeline to install a malicious Python wheel may be able to run code on that system with the same privileges as pip. This could lead to compromised developer workstations, poisoned build environments, stolen credentials or tokens, and unauthorized changes to software artifacts. The issue is not listed in CISA KEV, has very low EPSS, and has no known mature public exploitation, so it is lower urgency than remotely exploitable internet-facing flaws, but it should still be remediated anywhere Python package installation is performed with elevated privileges or in software supply-chain workflows.

How an attack unfolds

An attacker prepares a malicious wheel designed to place or expose Python modules that pip's self-update check may import after installation. The attacker then convinces a user, developer, administrator, or build system to install that wheel using a vulnerable pip version. After the wheel is installed, vulnerable pip performs its self-update check and imports module names that can resolve to code supplied by the newly installed package. The import triggers attacker-controlled Python code execution inside the pip process. From there, the attacker can perform actions available to that process, such as reading environment variables, accessing source code, stealing package repository tokens, modifying files, or establishing persistence, depending on local permissions and endpoint controls.

How to fix it

Upgrade pip to version 26.1 or later everywhere it is used, including developer workstations, build images, CI/CD runners, virtual environment templates, container base images, and system Python installations. Rebuild long-lived images that bundle vulnerable pip versions. Where immediate upgrade is not possible, reduce exposure by avoiding installation of untrusted wheel files, using isolated virtual environments, avoiding root or administrator execution of pip, pinning dependencies to trusted hashes, using a private package index or allowlist, and reviewing package contents before installation. Treat package installation as code execution, especially in build and release environments.

How to confirm the fix worked

Confirm remediation by running `python -m pip --version` or `pip --version` in each Python runtime, virtual environment template, CI image, and container image; the reported pip version should be 26.1 or later. Validate that automated build jobs and package installation scripts use the upgraded pip binary rather than an older system or virtualenv copy. For exposure review, inventory systems that installed wheels with pip earlier than 26.1, especially where pip ran as root, administrator, or a privileged service account. Confirm package installation workflows use trusted repositories, dependency pinning, and hash verification where feasible.

Typical attack path

1. Attacker creates or publishes a malicious Python wheel that can influence module imports during pip's post-install self-update check.
2. Victim user or automation installs the wheel using pip earlier than version 26.1.
3. The wheel is written to the Python environment before pip runs its self-update check.
4. pip imports a module name that resolves to code supplied by the newly installed package.
5. Attacker-controlled import-time code executes with the privileges of the pip process.
6. Attacker uses that execution to access local secrets, modify files, tamper with build outputs, or stage additional payloads.

How to detect it

There are no universal exploit indicators because exploitation depends on the specific malicious wheel and payload. To determine whether exploitation may have occurred, review pip install activity from systems that used pip before 26.1. Relevant sources include shell history, CI/CD job logs, build runner logs, pip verbose output, package manager logs, EDR process telemetry, file integrity logs, package index access logs, proxy/DNS logs, and artifact repository records. Look for installation of unfamiliar or externally supplied `.whl` files, pip executions as root or administrator, package installs immediately followed by unexpected child processes, outbound network connections from Python or pip, creation of persistence files, or access to secrets such as CI tokens, cloud credentials, SSH keys, and package publishing tokens. Inspect suspicious wheel contents for import-time code in top-level modules, unexpected network logic, obfuscation, credential access, or payload staging. Correlate package installation timestamps with endpoint alerts and network egress from the same host or build runner.

What your security team should do

• Upgrade all pip installations and build images to pip 26.1 or later, prioritizing CI/CD runners, release systems, developer base images, and hosts where pip runs with elevated privileges.
• Search endpoint, CI/CD, and shell history logs for recent installs of local, externally supplied, or unfamiliar `.whl` files using pip versions earlier than 26.1.
• Review dependency sources and package provenance for Python projects, especially any packages added or updated since publication of the vulnerability.
• Avoid running pip as root or administrator unless strictly required; use isolated virtual environments and least-privilege build accounts.
• Enforce dependency pinning and hash verification, such as `--require-hashes`, for sensitive build pipelines.
• Restrict package installation to approved internal indexes or curated mirrors where possible.
• Monitor for suspicious child processes, outbound network connections, or file modifications spawned by `pip`, `python -m pip`, or CI package-install steps.
• If suspicious package installation is identified, preserve the wheel file, pip logs, shell history, CI logs, and endpoint telemetry for forensic review.