The Python Package Index (PyPI) now rejects uploads of new files to releases older than 14 days to prevent attackers from poisoning long-stable releases if a project’s publishing tokens or release workflows are compromised.

“This change will protect Python users and reduce the amount of “cleanup” work associated with project compromises for PyPI admins. This restriction also means that compromises don’t put releases into an indeterminate and confusing state of both “compromised” and “not compromised”, where only a subset of files could be poisoned with malware,” Seth Larson, Security Developer-in-Residence at Python Software Foundation, explained.

PyPI has not defined semantics for releases that stop accepting new files and does not provide an API to determine a release’s status, so users should not rely on either. The project plans to define them after standardizing the Upload 2.0 API and Staged Previews under PEP 694, which proposes an extensible API for uploading files to a Python package index.

The proposal originated during discussions around PEP 740 (Digital Attestations) in January 2024 and resumed after the March 2026 compromise of the LiteLLM and Telnyx packages due to a mutable reference in those projects’ use of the Trivy GitHub Action.

It was initially postponed because some projects uploaded new files to older releases to add support for newer Python versions. PyPI analyzed the practice and found it was rare. Within the top 15,000 packages, only 56 uploaded a Python 3.14-compatible wheel more than 14 days after the original release, indicating the restriction will affect few projects.

PyPI Safety & Security Engineer Mike Fiedler proposed the change, which gained support during discussions at the 2026 Packaging Summit. Participants reached a rough consensus that projects should publish a new package version when adding support for newer Python releases instead of updating an existing release. Larson later implemented the change, and the patch was merged on July 8, 2026.