PyPI's analysis of the Ultralytics attack says the first malicious releases went out through the project's trusted publishing workflow, and later ones used an API token that had not been revoked. Attestations did not stop the first round, but they made the second visible.
What PyPI reports
Four versions of the ultralytics package were affected: 8.3.41, 8.3.42, 8.3.45 and 8.3.46. PyPI removed them. The post says no flaw in PyPI was used. The attacker compromised the project's GitHub Actions workflows, and later work found the attack targeted the GitHub Actions cache used during the build.
The project used Trusted Publishing. PyPI says the first round went out via the existing workflow. The second round used an API token that was still available to the workflow, possibly left over from before the project adopted Trusted Publishing.
What the attestations showed
Sigstore transparency logs and PyPI provenance attestations showed the first round came through the trusted workflow. The second round had no matching source repository activity and no publish attestations. That mismatch made it detectable.
This is the honest picture of attestation. A provenance record says which workflow built and published a file. It does not say the workflow was uncompromised. If an attacker controls the build, the record is accurate and the package is still bad.
The gaps PyPI lists
- Unused API tokens should be revoked once a project uses Trusted Publishing.
- PyPI does not warn when a GitHub Environment is used without the Trusted Publisher requiring it, and has opened tracking issues for it.
- Not every package is trustworthy, and users should review what they use.
- PyPI is working on malware reporting APIs and a quarantine status.
What publishers should do
PyPI's guidance includes auditing workflows for insecure patterns such as pull_request_target or shared caches, pinning dependencies with checksums, using Trusted Publishers, avoiding committed binaries, using MFA and avoiding SMS based 2FA. If compromised: delete bad releases, rotate every long-lived secret and share findings.
What consumers can do with provenance
- Check that a release has an attestation that matches the source repository you expect.
- Treat a release with no attestation, from a project that normally has them, as a reason to look closer.
- Do not read an attestation as a safety verdict. Combine it with review of dependency changes and a delay before adopting new versions.
See also signature, provenance and SBOM attestation compared.
What to take from it
Two habits stand out. First, clean up after a migration: when you adopt a safer publishing method, remove the old credential, because an unused token is still a working token. Second, compare where a release says it came from with what your repository history shows. A release with no matching activity is worth a question.
Quick check
Did trusted publishing fail here?
It worked as designed in that it tied publishes to a workflow. The attacker abused the workflow and a leftover token. PyPI's lessons focus on those two points.
What should I do with old API tokens?
Revoke any token you no longer need once publishing runs through a Trusted Publisher.
Sources
- PyPI blog, Ultralytics attack analysis, December 2024.
Last reviewed: 19 October 2026.
