Most breach notifications, however late, still come from the vendor. This one didn't. LiteLLM's publishing pipeline was compromised in March, two malicious package versions went out on PyPI, and the resulting trove of stolen secrets has spent the last five months sitting somewhere attackers could reach it before finally surfacing this week as a 153GB archive that researchers, not LiteLLM, are the ones notifying victims from. Help Net Security's coverage and Cybernews' reporting both pieced the timeline together the same way: a supply-chain compromise that took under an hour to execute, and a discovery process that took a season.
The scanner was the attack surface, not the target
LiteLLM is a widely used open-source proxy that lets engineering teams route calls to different AI model providers through one interface, which put its build pipeline in an unusually valuable position: it touches whatever credentials a team hands it to reach OpenAI, Anthropic, Azure or AWS-hosted models. Attackers didn't go after that pipeline directly. According to the reporting, a criminal group tracked as TeamPCP first compromised Trivy, the open-source vulnerability scanner that LiteLLM's CI/CD pipeline installed automatically without pinning it to a verified version. A poisoned Trivy release, once pulled into that pipeline, read the runner's environment and lifted LiteLLM's own PyPI publishing token - the exact credential needed to ship a malicious release under LiteLLM's real name.
Forty minutes, two package versions, one very large blast radius
With that token, TeamPCP published LiteLLM versions 1.82.7 and 1.82.8 to PyPI on 24 March. Version 1.82.8 added a litellm_init.pth startup hook - a file Python loads automatically the moment it starts, whether or not anything ever actually imports LiteLLM. Any CI runner, developer laptop or production container that installed the package in that window ran the payload, tracked as SANDCLOCK Stealer, without needing to use the library at all. Hudson Rock co-founder Alon Gal put the ratio in stark terms: "a window of roughly 40 minutes led to over 430,000 instances in which millions of secrets were harvested." The stolen material - AWS and Azure credentials, SSH keys, Kubernetes tokens, Salesforce client secrets, Slack signing secrets and AI provider API keys - sat compiled until security researchers obtained and analysed a 153GB archive of it this month, attributing 118,829 CI runner dumps to roughly 2,488 corporate domains, among them Nvidia, Volkswagen, Cisco, Samsung, AWS itself, FedEx, Microsoft, Salesforce and Deloitte.
A dependency you didn't choose, compromising a tool you didn't audit
The part of this chain worth sitting with isn't the stolen keys, it's the two steps it took to get to them. Nobody on the LiteLLM team had to make a mistake for this to happen; a scanner meant to catch vulnerabilities became the delivery mechanism for one, because it was pulled in unpinned and trusted by default. That's the same shape as the BdThemes plugin compromise, where the malicious code lived in a trusted feed rather than the plugin itself, and it's the structural weakness behind the ChainDrop npm worm before it: the actual vulnerable code is rarely the thing your team wrote or reviewed. It's the thing three dependencies upstream that nobody on your team has ever opened.
- Rotate every credential that touched a CI/CD pipeline running LiteLLM 1.82.7 or 1.82.8 between 24-25 March, even if you have no evidence of misuse - the archive is public now, not theoretical.
- Pin CI/CD tool versions, including security scanners, to a specific verified release rather than "latest"; Trivy's compromise reached LiteLLM only because that pin didn't exist.
- Check whether your own pipelines auto-install scanning or linting tools without a lockfile or hash check - the tooling you trust to find risk is itself a dependency with its own supply chain.
- Treat CI runner secrets as high-value targets by default: scope them narrowly, expire them aggressively, and assume anything a runner could read is something an attacker eventually will.
A breach that takes five months to surface is still a breach on day one - the clock just runs in the attacker's favour the whole time nobody's looking. If you need help auditing which of your pipelines trust an unpinned dependency the way LiteLLM's did, email sales@halfteck.com.