The pingdomv3 PyPI Revival Hijack

What happened

An attacker re-registered a deleted package name and published new releases under it. JFrog calls this technique Revival Hijack. PyPI lets anyone register a deleted name again. Pip shows no warning when a project upgrades to a release from a new owner. The JFrog report gives this timeline for pingdomv3:

• November 2019: the original author, cheneyyan, publishes version 0.0.2.
• April 2020: last legitimate release, 0.0.6.
• 27 March 2024: version 0.1 is a deprecation notice.
• 30 March 2024: the author deletes the project. An account named Jinnis re-registers the name and publishes version 1.0.0 as an apparent update.
• 12 April 2024: JFrog detects a version that holds the malicious payload.

The payload checks for the JENKINS_URL environment variable. This variable shows that the code runs in a Jenkins CI job. If it is present, the code fetches Python code from https://yyds.yyzs.workers.dev/meta/statistics and runs it with exec(). The code is wrapped in Base64 and uses no other obfuscation.

BleepingComputer and The Hacker News report that JFrog counted more than 22,000 removed PyPI packages open to this technique. The Hacker News notes the 12-day gap between registration and the malicious update.

Affected versions

• Clean: pingdomv3 0.0.6 and earlier, released by the original owner.
• Malicious: the releases that the new owner published after 30 March 2024, starting at 1.0.0. Our record lists 1.0.1 as the version with the payload.

Treat every pingdomv3 release above 0.0.6 as untrusted. The sources do not list a fixed release.

Indicators of compromise

• Domain: yyds.yyzs.workers.dev, path /meta/statistics.
• Code that reads JENKINS_URL and then calls exec() on content from a remote server.
• Package author changed from the original owner to a new account (Jinnis).
• Installed version above 0.0.6.

How to check

Check the installed version and the author on every build host.

pip show pingdomv3

Search your Python environments for the domain.

grep -rl "yyds.yyzs.workers.dev" $(python3 -c "import site;print(site.getsitepackages()[0])")

Check Jenkins jobs and requirements files for any entry that names pingdomv3. Review network logs from build agents for requests to the domain above.

What to do now

1. Remove pingdomv3 from your requirements and uninstall it from build images.
2. If a Jenkins job installed a release above 0.0.6, treat that agent as exposed. Rotate the credentials that the job can read.
3. Pin dependencies to exact versions and use hash checking.
4. Review package author changes before you upgrade, and watch for dependencies that were removed from PyPI.
5. Do not auto-update abandoned packages in CI.

Vigilance compares the version you trust with a new one. Here, the clean 0.0.6 gained decode-and-run code and a remote fetch in 1.0.1. A limit applies. The original owner deleted the earlier releases from PyPI, so the trusted baseline can no longer be downloaded from the index. Keep your own copy of versions that you trust.

What Vigilance showed

Vigilance compares the version you trust with the new one and names the file that gained a new capability. The block below is rebuilt from the public reports in the words Vigilance prints. It is not a captured scan, because the malicious release is not redistributed.

files scanned: 87 (1 Added)

HEADS UP  1 file can now do things the old version could not. The rest changed and gained nothing.

NEW FILE   setup.py
           It downloads from the internet.

Sources

1. jfrog.com/blog/revival-hijack-pypi-hijack-technique-exploited-22k-packages-at-risk/
2. bleepingcomputer.com/news/security/revival-hijack-supply-chain-attack-threatens-22-000-pypi-packages/
3. thehackernews.com/2024/09/hackers-hijack-22000-removed-pypi.html