Absolute path traversal in Python Packaging Authority pip can place files outside intended directories

pip would incorrectly handle doubly-encoded package URLs from indexes allowing for files to be installed to arbitrary locations on disk even when installing wheels. This vulnerability requires downloading or installing a package from a malicious package index to succeed, malicious packages alone are not able to exploit this vulnerability. Note that this vulnerability only materially impacts users running pip download with the --only-binary option as installing source distributions from an untrusted index is already an unsafe operation that executes code during install time.

• Python Packaging Authority pip: the CNA record marks versions starting at 0 and less than 26.2 as affected, using the python version type.
• The related GitHub advisory renders the same boundary as < 26.2.0 and names 26.2.0 as the patched version.
• The CNA default status is unaffected outside the listed range. Do not infer that every parallel or later release branch has been verified from this entry alone.

The flaw is in how pip processes a package filename obtained from an index-provided URL. Link.__init__ already percent-decodes the URL path into self._path, but Link.filename decoded the basename a second time. As a result, a doubly encoded separator such as %252F became %2F on the first pass and / on the second, turning a single component such as a%2Fb.whl into a/b.whl. The fix removes the second decode and adds join_within_directory so download-path joins treat the name as one path component. The attacker-controlled input is a package URL supplied by an index, and exploitation requires a user or automated process to download or install a package from a malicious index. The exact operating-system behavior, specific writable targets, and coverage of every download code path are not established by the public record.

The flaw is reachable through package-index content delivered over the network, but a malicious package alone cannot exploit it unless the package is downloaded or installed from a malicious index. Exploitation requires a user or automated process to perform the download or installation, and the vendor description identifies workflows using pip download with --only-binary as the materially affected case. The supplied scoring metadata is not fully consistent on some exploitability conditions, but it consistently describes a prerequisite download or installation action involving user interaction. The supplied record marks public_exploit as false and known_exploited as null, so no public exploit is recorded in that data and real-world exploitation status remains unconfirmed.

The flaw allows a filename from a package URL to escape the assumption that it is a single path component, which can cause a file to be written outside the intended download directory. The direct technical outcome is loss of file integrity within the permissions of the process running pip; the extent depends on that process's privileges and filesystem access. An automated build or CI environment that trusts an external package index could have workspace or other permitted files modified, but that is a possible consequence rather than a confirmed incident. The record does not establish unauthorized reading, loss of availability, privilege escalation, or impact to another system.

• A successful attack can affect system integrity by placing files at arbitrary locations that the pip process is permitted to write.
• The practical consequence depends on the account running pip and the files or directories that account can modify; build hosts and CI runners deserve attention when they automatically use untrusted indexes.
• The record does not identify a breach, victim, or campaign, so it does not establish that any particular environment has been changed.
• The documented effect is focused on integrity. No specific confidentiality or availability consequence is established in the record.

1. Upgrade pip to the confirmed patched release: 26.2.0. Verify the installed version on each host, image, and CI environment rather than updating only a lockfile or manifest.
2. Until the upgrade is complete, stop workflows that download or install packages from untrusted package indexes. This reduces the triggering condition but is not a substitute for patching.
3. Prioritize review and remediation of pipelines using pip download with --only-binary, because the vendor identifies this as the materially affected use case.
4. After upgrading, check prebuilt images, virtual environments, and bundled tooling so they no longer contain pip versions in the affected range. Do not extend the fixed-version conclusion to other branches without separate evidence.

• Inventory pip installations on developer workstations, build hosts, and CI runners, then compare the installed versions with the affected range in the record.
• Identify workflows that use pip download, especially those using --only-binary, and record the package indexes they can access.
• Review index, proxy, and mirror configuration for downloads from sources that are not trusted or approved by the organization.
• If affected activity is suspected, review filesystem changes during and after the download operation, focusing on locations outside the intended download directory that were writable by the pip process.
• No specific IOC or log signature is provided. The absence of matching telemetry does not prove that a system is safe.