PyPI Implements New Security Measures to Combat Package Poisoning Attacks
The Python Package Index (PyPI), a vital repository for Python developers, has recently introduced a significant security measure aimed at fortifying its supply chain. This new control prohibits publishers from uploading additional files to package releases that are older than 14 days. This policy shift is strategically designed to mitigate the risk of package poisoning attacks, where attackers may exploit compromised credentials or automation workflows to insert malicious code into previously trusted package versions.
This development, which was merged into the Warehouse codebase on July 8, 2026, marks a pivotal change in how package management is conducted within the Python ecosystem. The previous system permitted maintainers to add files indefinitely to established versions, thereby creating a long-standing vulnerability where a trusted release could become tainted over time.
Under the earlier model, if an attacker gained unauthorized access to a project’s PyPI token or release pipeline, they could upload harmful package artifacts masquerading as stable, trusted releases. This posed a significant threat to users, especially those whose environments automatically downloaded a platform-specific wheel that had not been previously associated with that particular version. While PyPI has clarified that it has not documented any instances of exploitation of this vulnerability, it acknowledged that there were no technical barriers in place to deter such incidents. The only preventative measure had been the attackers’ lack of awareness about the opportunity to exploit this gap.
The newly instituted 14-day limit enhances security by effectively rendering historical releases immutable after this period. This change significantly reduces the potential fallout from compromised maintainers, preventing scenarios where one artifact for a known version could be maliciously altered while others linked to that version remain legitimate. Mixed states, where some files in a release are untrustworthy, complicate vulnerability communications, package removals, and remediation efforts for maintainers, system administrators, and end users alike.
This proposal is rooted in ongoing discussions that began during the work on Python Enhancement Proposal (PEP) 740, which aimed to introduce digital attestations for Python package publishing back in January 2024. The conversation around these changes gained momentum in March 2026, largely prompted by the compromises of well-known packages like LiteLLM and Telnyx. These incidents were tied to mutable references in the projects’ implementations of third-party CI/CD dependencies, highlighting the inherent risks associated with relying on external workflows.
A key part of the discussion revolved around the practice of package maintainers appending new, Python-version-compatible wheels to existing releases after their initial publication. In order to address these practices, PyPI conducted a comprehensive analysis of historical publishing behaviors. Their examination focused on CPython 3.14-compatible wheels across the 15,000 most popular projects, discovering that only 56 of those projects had uploaded a compatible wheel more than 14 days after the respective release dates.
This finding sparked further conversation at the Packaging Summit held during PyCon US 2026, where attendees largely came to a consensus that it would be an acceptable trade-off for maintainers to release a new version if they wished to add compatibility for newly released Python runtimes. This adjustment implies that developers must now plan their version releases with greater foresight, rather than relying on the capacity to amend outdated package versions.
Despite these advancements, PyPI has understandably cautioned users against assuming the new behavior serves as a formal safeguard. Currently, the platform does not have established standardized semantics for releases that no longer accept file uploads, nor does it offer an API capable of verifying whether a release is considered closed. Users should be aware that these capabilities are anticipated to be formalized through the forthcoming Upload 2.0 API and staged preview mechanisms proposed in PEP 694.
In summary, PyPI’s implementation of the new 14-day restriction for file uploads reflects a proactive stance in securing the Python ecosystem against potential threats. As developers adjust to these changes, they are encouraged to enhance their version-release strategies to bolster security and maintain trust in the packages they use.