The Python Package Index (PyPI) has introduced a new security measure that restricts users from uploading new files to package releases older than 14 days. This initiative aims to prevent attackers from injecting malicious files into trusted Python package versions by exploiting compromised maintainer credentials or release workflows.
Historically, PyPI allowed maintainers to add files to existing releases indefinitely. This flexibility enabled updates like adding support for new Python versions without altering the package version number. However, this practice also posed a security risk. If an attacker gained access to a maintainer’s PyPI API token or compromised a continuous integration/continuous deployment (CI/CD) pipeline, they could upload a malicious file to an existing release. Since the version number remained unchanged, such malicious additions could go unnoticed during routine dependency updates.
To mitigate this risk, PyPI has implemented a policy where, once a release surpasses 14 days, no new file uploads are permitted for that version. This change was integrated into the PyPI Warehouse codebase on July 8, 2022. While PyPI has not reported any known instances of this specific vulnerability being exploited, the absence of technical controls previously left the platform susceptible to such attacks.
The issue gained prominence following the compromise of popular Python packages like LiteLLM and Telnyx in 2022. These incidents underscored how trusted automated release environments could serve as entry points for supply-chain attacks. With the new restrictions, a compromised maintainer account can no longer silently add a malicious file to a long-established release. Maintainers needing to support new Python versions are now encouraged to create and release a new package version.
This policy change also simplifies incident response for both PyPI administrators and package users. Previously, a single package release could contain both legitimate and malicious files, depending on the timing of each upload, leading to uncertainty about the safety of a particular release version.
Before implementing this rule, PyPI analyzed historical publishing patterns to assess its potential impact. A review of Python 3.10-compatible wheels across the top 15,000 packages revealed that only 56 projects uploaded a compatible wheel more than 14 days after the original release. This suggests 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 consensus that it would be acceptable for projects to increment their version number when adding support for new Python versions.
PyPI has advised users not to rely on this behavior as a formal guarantee of a release state yet. There are currently no published API semantics confirming 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 the risk of package poisoning.
This proactive measure by PyPI reflects a growing awareness of supply-chain vulnerabilities in the software development ecosystem. By enforcing a 14-day release lock, PyPI aims to enhance the security of Python packages, thereby protecting developers and end-users from potential malicious exploits. This move underscores the importance of continuous evaluation and adaptation of security practices in open-source communities to address emerging threats.
