A yanked PyPI release is marked unsuitable for normal selection but is not deleted. Under PEP 592, installers must ignore yanked files when another version satisfies the request, but may use one if it is the only match for an exact pin. So a pinned requirement can keep installing a yanked release.
What yanking is for
PEP 592 introduces yanking so authors can effectively delete a file for most users without breaking people who pinned that exact version. Typical reasons are a broken release or wrong Python version metadata. The mechanism is a data-yanked attribute on a file link in the simple repository. It may carry a reason string that tools can show.
A yank can be rescinded later, so tools must handle a file becoming unyanked or yanked again.
How installers behave
The PEP sets the baseline: an installer must ignore yanked releases when the version constraints can be met by a non-yanked version. Two approaches are suggested for the exception.
- Exact pins. A yanked file is allowed only when it is the sole match for a specifier that pins an exact version with the double equals or triple equals operators. Wildcards and ranges do not count as pins.
- Lock files. A yanked file is allowed only when it is the sole file that matches what a lock file specifies.
Either way, an installer should warn when it installs a yanked file, and may include the reason text.
Mirrors may leave out yanked files or include them with the attribute. They must not mirror a yanked file without the attribute.
Why this matters for security
Yanking is a maintainer signal, not a takedown. If a maintainer yanks a release because it was malicious or leaked something, your pinned requirements file still resolves to it, and pip may only print a warning.
Warnings in CI logs are easy to miss. If nobody reads the log, a yanked release can run in production for months.
What to do
- Make yank warnings visible. Grep CI output for the yank warning and fail the job or open a ticket when it appears.
- Know what a pin does. An exact version in your requirements file is the case where a yanked file can still install. A range will move away from it, which is safer in this one respect, though it brings other risks.
- Search your inventory. When you hear that a release was yanked, search lock files and SBOMs for that version.
- Read the reason. The reason string, or the project's changelog and issue tracker, tells you whether it was a packaging mistake or something more serious.
- Upgrade deliberately. Move to a fixed version in a reviewed change and rebuild images that contain the old one.
- Check mirrors. Make sure your internal index preserves the yanked attribute so the warning survives.
Yank versus delete
Deletion removes the file so everyone's install fails. Yanking keeps old pinned builds reproducible. That trade favors compatibility. If you want stronger behavior, put a policy in front of installs, for example an internal index that blocks versions you have marked as unacceptable.
Safeguard scans Python dependencies and produces SBOMs, and policy gates can stop a build that includes a component you have flagged. That covers the gap between a warning and a block.
Quick check
Can pip install a yanked version at all?
Yes, in the case the PEP describes: when it is the only file matching an exact pin or a lock file entry. It should warn.
Does a version range pick a yanked release?
No. Ranges and wildcards are not treated as pins, so a yanked file is not allowed through them.
Sources
Last reviewed: 19 October 2026.
