Incident Overview
On December 5, 2024, attackers compromised the Ultralytics YOLO library’s GitHub Actions workflow to publish four malicious versions (8.3.41, 8.3.42, 8.3.45, and 8.3.46) to PyPI. These versions contained a modified utils/download.py file that executed the XMRig cryptocurrency miner when installed.
The compromised packages were removed from PyPI after detection, and the incident highlighted vulnerabilities in CI/CD supply-chain security for widely used machine learning libraries. PyPI’s analysis confirmed no flaws in their platform were exploited, but the attack demonstrated how attackers can manipulate build pipelines to inject malicious code.
The attack underscored the risks faced by ML pipelines and development tooling reliant on third-party dependencies.
Possible Root Cause
The first phase of the attack involved the compromise of the GitHub Actions cache used during the build process. Attackers injected malicious code into the build pipeline, altering the utils/download.py file in the published wheel without changing the source repository. This discrepancy between GitHub and PyPI indicated the attack targeted the build environment rather than the source code directly.
The second phase used an unrevoked PyPI API token, likely a remnant from before the project adopted Trusted Publishing. This token allowed the attacker to publish additional malicious versions without corresponding source repository activity or provenance attestations.
The attack succeeded because the project’s build workflow relied on shared caches and did not enforce strict provenance checks. The use of Trusted Publishing for some releases did not prevent the compromise, as the attacker still had access to an unused API token.
Takeaways
The incident revealed critical weaknesses in CI/CD security for open-source projects, particularly those using GitHub Actions and PyPI.
- Projects must audit workflows for insecure patterns like shared caches and unused credentials.
- Provenance and attestations as defenses: The lack of provenance attestations for the second set of malicious releases made the attack detectable. Tools like Sigstore and PyPI’s publishing attestations can help verify software origins at install time, reducing the effectiveness of such attacks.
- Trusted Publishing is not foolproof: While Trusted Publishing limits credential exposure, projects must ensure all long-lived secrets (e.g., API tokens) are revoked when no longer needed. The attack used an unused token, demonstrating that credential hygiene remains essential.
- Collaborative incident response: Ultralytics’ public disclosure of actions taken (e.g., removing malicious versions, rotating secrets) allowed PyPI and security researchers to investigate and mitigate the threat more effectively.
- PyPI’s role in malware detection: PyPI staff rely on manual and automated reports to remove malicious packages quickly. New systems, such as quarantine release statuses and researcher APIs, aim to reduce malware availability in 2025. However, user vigilance remains critical, as PyPI cannot pre-vet all packages.
- Best practices for publishers: Projects should adopt measures such as pinning dependencies, avoiding binary commits, and enforcing multi-factor authentication (MFA) with hardware keys. These steps significantly raise the bar for attackers targeting open-source supply chains.
The attack on Ultralytics serves as a case study for the broader risks in ML and development tooling ecosystems. It emphasizes the need for continuous security audits, credential management, and adoption of emerging provenance technologies to safeguard open-source dependencies.