Your build pipeline runs code from a scanner that runs code from a package that runs code from another package. Sit with that for a second. This week CloudSEK put a number on the trust chain: roughly 434,000 CI/CD pipelines across about 2,500 companies were exposed by what it is calling the LiteLLM attack, and the entry point was not LiteLLM.
The chain, in order
The CloudSEK writeup, as reported by devops.com, walks the compromise backwards. The attackers reached Trivy, Aqua Security's vulnerability scanner, first. From Trivy they pivoted into LiteLLM's build system. From that build system they cut two malicious LiteLLM releases (1.82.7 and 1.82.8) and pushed them to PyPI. The devops.com summary of it is worth reading twice: "one un-revoked token, three tools deep". The two packages sat live on PyPI for about forty minutes before being removed. Forty minutes is more than enough when your CI is on a fresh-install cron.
What the payloads went after
Names matter here because they tell you what to rotate. The report cites CanisterWorm going after cloud tokens and generic API keys, SandClock aimed at AWS credentials and Kubernetes tokens, and Mini Shai-Hulud and Miasma as self-replicating worms scoped at npm and PyPI. The FBI's line, quoted in the same coverage, is the one to internalise: treat exfiltrated data and credentials as a persistent risk. Your token did not become safe when PyPI pulled the release.
The uncomfortable part
Two things about the CloudSEK count matter more than its round shape. First, 434,000 is a count of pipelines, not accounts; that is how these compromises actually propagate, one poisoned dependency cloning into many CI jobs each. Second, the initial hop was a security tool. A scanner. The thing you added specifically to catch this. (Comforting, isn't it?)
Signed images and provenance attestations do not save you on this one, because the malicious builds came out of the real project's real pipeline. So rotate anything the two poisoned versions could see, revoke the tokens with the widest blast radius first, then go audit the credentials your scanner holds. Yes, that scanner.
Top comments (0)