PyPI Blocks New File Uploads on 14-Day-Old Releases to Prevent Package Poisoning Attacks

PyPI has introduced a new security measure that prevents users from uploading new files to package releases that are more than 14 days old. This change aims to stop attackers from adding malicious files to trusted Python package versions after compromising a maintainer’s publishing token or release workflow.

The Python Package Index (PyPI) has begun rejecting new uploads for releases older than 14 days. This restriction was integrated into the PyPI Warehouse codebase on July 8, 2022, and addresses a software supply-chain risk created by allowing “open-ended” releases.

Previously, package maintainers could publish additional files to an existing release at any time. For example, a maintainer might upload a new wheel for a newer version of Python while keeping the same package version number.

While this flexibility was useful for compatibility, it also presented an opportunity for attacks. If an attacker gained access to a PyPI API token, compromised a CI/CD pipeline, or abused a trusted publishing workflow, they could upload a malicious wheel to an old release that developers considered safe.

Since the version number would not change, identifying the malicious file during routine dependency updates would be more challenging. The new rule limits this risk. Once a release is older than 14 days, PyPI will no longer accept new file uploads for that version.

PyPI has indicated that it has not been aware of attackers exploiting this specific vulnerability previously. However, the platform noted that no technical controls existed to prevent such scenarios, except for the understanding that attackers may not recognize the opportunity.

PyPI 14 Days Locks

The issue gained prominence after the compromise of popular Python packages LiteLLM and Telnyx in 2022. These incidents highlighted how trusted automated release environments could be entry points for supply-chain attacks.

With the new restrictions in place, a compromised maintainer account can no longer silently add a malicious file to a long-established release. Maintainers needing to publish support for a new version of Python will typically need to create and release a new package version instead.

This change also simplifies incident response for both PyPI administrators and package users. Under the previous model, a package release could contain both legitimate and malicious files, depending on when each file was uploaded, leaving users uncertain about the safety of a particular release version.

Before implementing this rule, PyPI reviewed historical publishing patterns to understand its potential effects. This analysis included projects that had added files after a release had already been published.

A review of Python 3.10-compatible wheels across the top 15,000 packages found that only 56 projects uploaded a compatible wheel more than 14 days after the original release, suggesting that requiring a new package version would have minimal impact on most maintainers.

The proposal was also discussed at the Packaging Summit during PyCon US 2022, where participants reached a rough consensus that it would be acceptable for projects to increment their version number when adding support for new Python versions.

PyPI has cautioned users not to rely on this behavior as a formal guarantee of a release state yet. There are currently no published API semantics that confirm whether a release is open or closed for uploads.

Such definitions are expected to emerge through the proposed Upload 2.0 API and staged previews described in PEP 694. Until then, the 14-day limit serves as a practical security safeguard against a subtle but significant risk of package poisoning.

 Strengthen Your SOC by Accelerating Threat Detection & Rapid Investigations. -> Integrate ANY.RUN With Your SOC Now.