CVE-2026-3219

What it actually does

pip did not adequately validate archive type ambiguity when processing source distributions or local archive inputs. A crafted archive that is both a valid tar file and a valid ZIP file, or a concatenation of tar and ZIP content, could be treated by pip as a ZIP archive regardless of filename or apparent tar identity. This can cause pip to extract and install a different set of files than a reviewer, automation, or policy control expected based on the file extension or tar content. The primary security impact is low-integrity compromise of the installation outcome: unintended package files, setup metadata, or build scripts may be selected for installation if a user or automated process installs the crafted archive.

Why it matters to the business

The main business risk is supply-chain confusion during Python package installation: developers, CI jobs, or release tooling could install code that differs from what was expected or reviewed. Because exploitation requires a user or automated process to install a malicious or untrusted archive locally, and because EPSS is very low at 0.00144 with no known KEV listing or reported ransomware use, broad exploitation urgency is lower than remotely exploitable package-manager flaws. However, organizations that rely heavily on pip in build pipelines, artifact ingestion, or internal package distribution should still prioritize remediation because a successful attack could introduce untrusted code into software builds or developer workstations.

How an attack unfolds

An attacker prepares an archive with ambiguous structure, such as a file that can be interpreted as both tar and ZIP, or concatenated tar and ZIP data. The attacker gives the file a name or appearance suggesting one archive type while embedding different installable package contents in the portion pip chooses to process as ZIP. The attacker then convinces a developer, build job, dependency update process, or internal package ingestion workflow to run pip against the crafted archive. Under vulnerable behavior, pip proceeds using ZIP interpretation even when the filename or alternate archive identity suggests tar, causing pip to extract and install files that may differ from those expected by a reviewer or automated control. If the selected contents include malicious package metadata, build hooks, or Python code, that code may execute during build or later runtime depending on how the package is installed and used.

How to fix it

Upgrade pip to a version that implements unambiguous archive validation for tar and ZIP inputs. The fixed behavior should only proceed when an archive identifies uniquely as one supported format and should reject files that are simultaneously valid as multiple archive types. No exact fixed version was provided in the input, so security teams should use the latest patched pip release from the Python Packaging Authority or vendor-supported Python distribution once available. As mitigation, avoid installing packages directly from untrusted local archives or arbitrary URLs, require packages to come from trusted indexes or signed internal artifact repositories, and add validation in build pipelines to reject archives that are valid as more than one format. Prefer hash-pinned dependencies, lock files, reproducible builds, and controlled package sources for CI/CD environments.

How to confirm the fix worked

Confirm the installed pip version is at or above the vendor-patched release level across developer workstations, CI images, build containers, base images, and package publishing systems. Test by attempting to install a deliberately ambiguous tar/ZIP test archive in a non-production environment: fixed versions should reject the archive rather than silently treating it as ZIP. Review build and dependency-management workflows for direct installation from local files, pull-request artifacts, issue attachments, or external URLs. Validate that package policies require trusted repositories and hash verification where feasible. For containerized build systems, confirm base images have been rebuilt after the pip update rather than only updating runtime hosts.

Typical attack path

1. Create a Python package archive that is intentionally ambiguous and valid as more than one archive format, such as both tar and ZIP.
2. Place benign-looking or expected content in the archive view likely to be inspected by humans or tooling.
3. Place different package files, metadata, or build/install behavior in the archive view pip will process.
4. Distribute the crafted archive through a pull request, issue attachment, internal package feed, compromised mirror, direct download link, or other channel that could reach a developer or build system.
5. Cause a user or automated workflow to install the archive with pip.
6. Rely on vulnerable pip behavior to select the ZIP interpretation and install the attacker-controlled contents.
7. Use installed code, package build hooks, or altered dependencies to affect the developer workstation, CI runner, or downstream software artifact.

How to detect it

Look for evidence that pip installed packages from manually supplied archives, direct URLs, pull-request artifacts, issue attachments, or other non-standard sources around the time untrusted code could have entered the environment. Useful sources include CI/CD job logs, build runner shell history, package installation logs, artifact repository access logs, developer endpoint command history, EDR process telemetry, proxy logs for downloaded package artifacts, and source-control events that introduced package archive files. Focus on pip commands that install local .tar, .tar.gz, .tgz, .zip, or extension-mismatched archives, especially where the same artifact was not obtained from a trusted package index or where package contents differ between manual inspection and installed files. For forensic review, preserve suspicious archives and test whether they are accepted by both tar and ZIP parsers; ambiguous archives should be treated as suspicious in this context. There are no named threat actors, public exploit maturity, KEV status, or ransomware associations provided for this vulnerability, so detection should be behavior- and artifact-focused rather than actor-IOC-focused.

What your security team should do

• Inventory pip versions across developer endpoints, CI runners, build containers, and Python base images.
• Upgrade pip to the latest patched version supplied by PyPA, operating system vendors, or approved Python distribution channels.
• Prioritize build infrastructure and software release pipelines before lower-risk developer-only systems because compromise there can affect downstream artifacts.
• Block or tightly control pip installs from arbitrary local archives, external URLs, and unreviewed attachments.
• Require trusted package indexes, dependency pinning, and hash verification for production builds.
• Add artifact validation to reject files that can be interpreted as both tar and ZIP archives.
• Review recent dependency and build logs for installs from unusual archive filenames, unexpected direct URLs, or manually supplied package artifacts.
• Monitor Python packaging advisories for the exact fixed version if not already available through normal package-management channels.