PyPI has introduced a new supply-chain security control that prevents publishers from uploading additional files to package releases older than 14 days, reducing the risk of attackers poisoning previously trusted versions after compromising project credentials, automation workflows, or publishing tokens.
The Python Package Index (PyPI) has begun rejecting new distribution files uploaded to releases that are more than 14 days old, a security-focused change designed to prevent package poisoning attacks against established Python projects.
The restriction, merged into the Warehouse codebase on July 8, 2026, addresses the long-standing risk created by “open-ended” releases, where maintainers could add wheels or source distributions to an already-published version indefinitely.
PyPI Blocks New File Uploads
Under the previous model, an attacker who gained access to a project’s PyPI token or release pipeline could upload a malicious package artifact under an older, widely trusted version number.
This could allow the attacker to target users whose environments download a platform-specific wheel not previously available for that release. While PyPI said it is not aware of this capability having been exploited, the platform noted that no technical barrier had prevented abuse beyond attackers not recognizing the opportunity.
The rule limits the damage a compromise can cause by making historical releases effectively immutable after the 14-day window. It also helps avoid a difficult incident-response scenario in which one artifact for a version is malicious.
At the same time, other files tied to the same release remain legitimate. Such mixed states can make vulnerability communications, package removals, and cleanup efforts more complex for maintainers, administrators, and downstream users.
The proposal was initially discussed during work on PEP 740, which introduced digital attestations for Python package publishing, in January 2024.
Discussion resumed in March 2026 following compromises affecting the LiteLLM and Telnyx packages. Those incidents were linked to a mutable reference used in the projects’ implementation of the Trivy GitHub Action, illustrating how third-party CI/CD dependencies can expose trusted software release workflows to supply-chain compromise.
One concern was that package maintainers sometimes add new Python-version-compatible wheels to an existing release after publication. PyPI examined historical publishing behavior to measure the likely impact.
In an analysis of CPython 3.14-compatible wheels among the 15,000 most popular projects, only 56 projects uploaded a compatible wheel more than 14 days after the release had first become available.
At the Packaging Summit during PyCon US 2026, attendees generally agreed that requiring maintainers to publish a new version to add support for a newly released Python runtime was an acceptable tradeoff for stronger ecosystem security.
The change means projects should plan version releases more deliberately, rather than relying on the ability to attach files to old package versions.
PyPI cautioned that users should not yet depend on the behavior as a formal guarantee. The service has not defined standardized semantics for releases that no longer accept files, nor does it currently provide an API for checking whether a release is closed.
Those capabilities are expected to be formalized through the Upload 2.0 API and staged preview mechanisms proposed in PEP 694.
ALERT: 20+ government sites delivered malware to businesses and citizens. See full attack research to check your own exposure.
