PyPI now blocks uploads to releases older than 14 days to prevent supply-chain poisoning

PyPI blocks old-release uploads to close supply-chain gap

If you have ever pinned a Python dependency to an exact version, you probably assumed the underlying code would never change. Until this week, it could have. PyPI now rejects new file uploads to any package release older than 14 days 1.

The fix targets a specific attack path. If a maintainer's publishing token or CI workflow gets compromised, an attacker could upload a new file to a release that shipped months or years ago, one that thousands of projects already pin in their dependency files. The old version number stays the same. The package metadata looks unchanged. But the code behind it is poisoned 1.

PyPI's team says this attack has not been seen in the wild. They are not claiming it was impossible. As they describe it, no technical barrier stopped anyone from trying; attackers simply had not realized the upload path existed 1. Seth Larson, who published the announcement on the PyPI blog, framed the change as proactive hardening rather than incident response 2.

The gap was structural. A package last updated in 2019, still downloaded daily by automated build systems, remained mutable. After this change, a release freezes at the 14-day mark. Need to ship a fix? Create a new release version. That has always been best practice, but the registry never enforced it.

Maintainers who occasionally patched old releases in place, attaching a missing source distribution or correcting packaging metadata without cutting a new version, will need to adjust 3. The convenience of mutable old releases was also the exact mechanism an attacker would use to inject malicious code into a version the ecosystem already trusts 1.

The change follows a year of real supply-chain incidents on the platform. In April 2026, PyPI published an incident report on attacks targeting litellm and telnyx, both popular PyPI packages 1. In November 2025, the Shai-Hulud campaign, a self-propagating attack that spread through the npm ecosystem and exfiltrated credentials from open source projects, led PyPI to revoke exposed tokens after finding PyPI credentials in compromised repositories 1.

Those incidents were reactive. The 14-day upload freeze is not.

PyPI has also been building complementary defenses. Its Trusted Publishing system, available since 2023, lets build platforms obtain short-lived, scoped tokens for each build instead of relying on long-lived publishing credentials 1. The 14-day freeze reduces the blast radius of any token that does get stolen. Even a fully compromised maintainer account cannot inject new files into a release that has already settled into dependency trees worldwide 1.

PyPI serves over a million users across more than 700,000 projects 1. A meaningful share of those projects have releases sitting untouched for months or years, still pulled by build systems that pin exact versions. Before this change, each dormant release was an injection point with no expiration date.

For security teams, the version string in a lock file was not, until this week, a guarantee that the underlying code had not changed since the last audit. The 14-day window narrows the mutation opportunity from indefinite to two weeks. After that, a published release is frozen. What pip install pulls down is what was actually uploaded.