Can Deleted PyPI Packages Be Hijacked? What It Means for Your CI/CD Security

JFrog security researchers reported that the PyPI package repository is vulnerable to attacks where malicious packages are uploaded using the same name as previously deleted packages. If continuous integration tools such as Jenkins trust and install these packages, automatic infection can occur.

When a project is removed from PyPI, its package name becomes immediately available to other users. Attackers can re‑use that name, and developers may unknowingly download a malicious version, believing it to be the original.

This technique is more powerful than domain squatting because there is no indication that a previously trusted package now belongs to a new owner. The researchers demonstrated the attack by creating a package, deleting it, and then replacing it with a same‑named package from a different account with a higher version number, successfully fooling pip.

They observed that running pip list --outdated shows the impostor as merely a “new version” (e.g., 4.0.0) – same name but completely different code.

According to the paper, PyPI deletes about 300 packages each month. Even after filtering out packages with more than 100,000 downloads or that have been active for over six months, the researchers identified over 22,000 packages that could potentially be hijacked.

The team also reserved a small set of popular vulnerable package names as empty packages to prevent hijacking. In three months, these empty packages were downloaded nearly 200,000 times, indicating that outdated jobs and scripts still search for deleted packages or users manually download them due to name squatting.

One concrete case involved the package pingdomv3 . The original Pingdom API is a monitoring service operated by SolarWinds, but pingdomv3 was an independent project last updated in 2020. The original author removed it from PyPI on March 30 2024; shortly after, a new developer claimed the name and uploaded a malicious version on April 12, which was reported and promptly removed.

The malicious payload’s details were not disclosed, but it downloads a script and executes it via Python’s exec command, assuming the package runs in a Jenkins environment.

Although the study was reported to PyPI in May, the JFrog team said they have not received a response. They advise PyPI users to stay vigilant and ensure their CI/CD pipelines do not attempt to install packages that have been removed from PyPI.

PyPI security engineer Mike Fieldler recently announced several technical measures to improve security: mandatory two‑factor authentication for all accounts, security audits, an enhanced malware reporting process (90 % of issues resolved within 24 hours), new quarantine options for suspicious packages, and improvements to the PyPI codebase (the Warehouse application).