PyPI Blocks New File Uploads on Old Releases to Prevent Package Poisoning

Key Takeaways

• PyPI has implemented a new security measure preventing new file uploads to package releases older than 14 days.
• This change addresses a software supply-chain risk by mitigating the ability for attackers to “poison” trusted, older package versions.
• The restriction aims to prevent malicious files from being silently added to established releases if a maintainer’s account or CI/CD pipeline is compromised.
• While no direct exploits of this specific vulnerability have been confirmed, the measure proactively closes a potential attack vector.

The Python Package Index (PyPI) has rolled out a significant security enhancement, now blocking the upload of new files to package releases that are more than 14 days old. This strategic move is designed to fortify the software supply chain against potential package poisoning attacks, where malicious code could be injected into seemingly stable and trusted Python package versions.

Addressing a Supply Chain Vulnerability

Integrated into the PyPI Warehouse codebase on July 8, 2022, this new restriction targets a vulnerability stemming from what was previously an “open-ended” release model. Historically, package maintainers enjoyed the flexibility of adding new files to an existing release at any point. A common use case for this was uploading a new wheel file to support a newer Python version while retaining the original package version number.

While convenient, this flexibility also presented a critical security gap. Should an attacker gain unauthorized access to a PyPI API token, compromise a continuous integration/continuous deployment (CI/CD) pipeline, or exploit a trusted publishing workflow, they could surreptitiously upload a malicious wheel to an older release. Developers, relying on the unchanged version number, might unknowingly integrate compromised code, making detection difficult during routine dependency updates.

PyPI has stated that it has no evidence of attackers actively exploiting this specific vulnerability prior to the change. However, the platform recognized the absence of technical controls to prevent such scenarios, leaving the door open for potential abuse.

Impact of the 14-Day Lock

The impetus for addressing this issue gained traction following high-profile compromises of popular Python packages like LiteLLM and Telnyx in 2022. These incidents underscored how automated release environments, when compromised, could become critical entry points for sophisticated supply-chain attacks.

With the new restrictions in place, a compromised maintainer account can no longer silently append malicious files to long-established releases. Maintainers who need to add support for new Python versions will now typically be required to create and publish a new package version, rather than modifying an old one. This approach enhances transparency and makes it easier to track changes.

Furthermore, this change streamlines incident response for both PyPI administrators and package users. Under the previous system, a single package release could contain a mix of legitimate and malicious files, depending on their upload timestamps, creating ambiguity about the integrity of any given release version. The new rule simplifies this, ensuring that once a release is 14 days old, its file set is considered immutable.

Before implementing this policy, PyPI conducted an extensive review of historical publishing patterns to gauge its potential impact. An analysis of Python 3.10-compatible wheels across the top 15,000 packages revealed that only 56 projects had uploaded a compatible wheel more than 14 days after the original release. This data suggested that requiring a new package version for such updates would have a minimal disruption on the majority of maintainers.

The proposal was also a key discussion point at the Packaging Summit during PyCon US 2022, where a general consensus emerged that incrementing version numbers for new Python version support would be an acceptable practice.

PyPI advises users not to rely on this new behavior as a formal guarantee of a release’s immutable state just yet. Currently, there are no published API semantics that explicitly confirm whether a release is open or closed for uploads. Such definitions are anticipated to be introduced through the proposed Upload 2.0 API and staged previews outlined in PEP 694. Until then, the 14-day limit stands as a crucial, practical security measure against a subtle yet significant risk of package poisoning.

What You Should Do

• Verify Package Hashes: Always verify the integrity of downloaded packages against published hashes when possible, especially for critical dependencies.
• Monitor Dependencies: Implement robust dependency scanning tools to detect any unexpected changes or new vulnerabilities in your project’s dependencies.
• Update Regularly: Keep your Python packages and environment up-to-date, prioritizing new stable releases that incorporate the latest security fixes.
• Follow PyPI Announcements: Stay informed about official PyPI security announcements and best practices for package maintainers and users.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.