We covered the Trivy compromise back in June, when it emerged that a poisoned version of the popular scanner had breached the European Commission’s AWS cloud. New research shows that attack had a second, much larger victim nobody had fully measured until now.
A three-hour window, five months of hidden exposure
On 24 March 2026, the threat actor group TeamPCP, using access obtained through its earlier compromise of Trivy’s GitHub Actions pipeline, pushed two malicious releases of LiteLLM, a widely used open source LLM gateway and proxy, to PyPI: versions 1.82.7 and 1.82.8. LiteLLM’s own CI pipeline had pulled in the compromised Trivy action, and the attackers used that foothold to push a credential-stealing package to LiteLLM’s roughly 3.4 million daily downloads. The malicious versions were live for approximately three hours before PyPI quarantined them, and the second release added a .pth file that executed the infostealer automatically the moment Python started, no explicit import required.
What the payload actually did
The malicious code targeted AWS, GCP, GitHub and SSH credentials, environment files and in-memory secrets on any CI/CD runner where it executed, along with LLM API keys and gateway configuration, giving attackers a route into whatever AI systems those pipelines connected to. Beyond credential theft, researchers documented attempted lateral movement across Kubernetes clusters and installation of a persistent systemd backdoor that polls for further payloads, meaning a three-hour exposure window on PyPI does not translate to a three-hour incident on any environment that actually pulled the package.
Why the number changed five months later
CloudSEK’s newly published dataset links the compromised path to more than 2,500 organisations and 434,000 CI/CD pipeline runs, a scale that was not visible at the time of the original March disclosure. Exposure is not proof of breach in every case, but it is a considerably larger population than most incident retrospectives assumed had closed out months ago. That gap between initial disclosure and fully understood impact is the real lesson here: a supply chain compromise that looks contained at the time can still be quietly reshaping an organisation’s actual risk exposure long after the postmortem is filed and everyone has moved on.
What this means if LiteLLM was ever in your pipeline
If any build environment installed LiteLLM between 24 March and the point PyPI pulled the package, treat every credential present in that environment during the window as potentially compromised, not just the ones you already rotated in the spring. That includes cloud provider keys, GitHub tokens, SSH keys, Kubernetes service account tokens and LLM API keys, and it is worth specifically checking for systemd persistence mechanisms that would have survived a simple credential rotation. Given how quickly AI tooling gets adopted inside European engineering teams, often outside the formal software approval process that would normally flag a dependency like this, confirming whether LiteLLM was ever pulled into a pipeline is a reasonable question for any team to be asking this week even if it feels like old news.
If your organisation used LiteLLM, Trivy, or any of the affected GitHub Actions in your CI/CD pipelines and wants an independent check for lingering compromise, help rotating credentials that may still be exposed five months on, or a review of how AI tooling enters your build environment in the first place, contact Excello Digital. We help European engineering teams find out what a supply chain incident actually cost them, not just what it looked like on day one.