Why pip 26.2.0 matters when an index returns doubly encoded URLs
pip parses package indexes as structured data, but a URL can be encoded more than once before it reaches the installer. CVE-2026-13346 covers a handling error in pip versions before 26.2.0. A malicious package index could use doubly encoded package URLs to make pip install files at arbitrary locations on disk, including when it installs a wheel.
The scope is important. Malicious packages alone are not enough, and the public advisory does not describe an attack that works without an index the client already trusts. The issue requires downloading or installing from a malicious index. The most material case is pip download with --only-binary, according to the advisory. Installing a source distribution from an untrusted index is already unsafe because build-time code can run.
That does not make the bug irrelevant. Organizations often use a trusted package set but do not control every index response, redirect, cache, or mirror that a build system contacts. A wheel is normally treated as a data artifact, which can create a false sense that path handling is less dangerous than source execution. The reported impact is a file write outside the intended installation location.
Treat index trust as a supply-chain control
Upgrade pip to 26.2.0 or later in every environment that resolves packages. That includes developer workstations, CI runners, container build stages, and release automation. An application dependency scan can miss the installer version if it only examines application packages.
Pin internal indexes and require TLS for index connections. Keep an allowlist of resolvers and mirrors, and review redirect behavior rather than assuming that the first hostname determines where content came from. Use hash-checked requirements or a lock file produced by a trusted resolver. Hashes establish that the downloaded artifact is the expected one, but they do not repair a parser that chooses the wrong destination path.
Generate wheels into a disposable directory owned by the build job. Run builds with a read-only source tree and no write access to the user home directory, system package paths, or deployment scripts. Inspect resolved filenames and output paths in CI when an index returns unexpected metadata. A normal successful install can still leave a useful warning in the resolver log.
Run dependency installation and application tests in separate jobs. If the installer writes an unexpected file, the test job should not inherit credentials or deployment permissions from the build job. Keep build caches scoped per project and invalidate them when the installer is upgraded.
Add a regression check that compares reported package URLs with the downloaded filename and the final destination. Upgrade pip in the base image as well as in the project environment, then verify the version that actually executed. The last point matters because a wrapper script may call a different binary than the package manager used during manual testing.
