The tool that was supposed to check the code for problems was the problem. That is the short version of how attackers got into more than two thousand companies at once, and it is the detail that should keep security teams up tonight.
A 153GB archive of credentials stolen in the LiteLLM supply chain attack has now surfaced publicly. Security firm Hudson Rock analyzed it and found 433,909 files, including 118,829 dumps taken from CI runners, which it attributed to 2,488 corporate domains. The names inside read like a list of the world’s most important engineering organizations.
The Attack Chain, Step by Step
What makes this incident worth studying is that no single step in it was exotic. Every link in the chain was a normal, sensible engineering practice being used exactly as intended.
| Date | What happened | Why it worked |
|---|---|---|
| March 19, 2026 | TeamPCP uses stolen credentials to publish a compromised version of Trivy, an open source vulnerability scanner | Trivy is trusted infrastructure, installed automatically by thousands of build pipelines |
| Days after | LiteLLM’s CI pipeline auto-installs the poisoned scanner, which reads the runner environment and captures LiteLLM’s PyPI publishing tokens | A security scanner needs broad read access by design, so nothing looked wrong |
| March 24, 2026 | Malicious LiteLLM 1.82.7 and 1.82.8 published to PyPI using the stolen tokens | The releases were cryptographically legitimate; they came from the real account |
| ~40 minutes | The packages stay live before removal, executing on every Python invocation with no explicit import required | Automated builds run constantly, so 40 minutes covers an enormous number of pipeline executions |
| July 2026 | The FBI issues a FLASH advisory warning that the stolen credentials could still be weaponized | Harvested secrets stay valid until someone actually rotates them |
| August 13, 2026 | A 153GB archive with 433,909 files and 118,829 CI runner dumps surfaces and is tied to 2,488 corporate domains | What was a theoretical exposure becomes a public one |
Nobody Attacked LiteLLM
This is the part that breaks the usual mental model. TeamPCP, a group that emerged in late 2025, never went after LiteLLM directly. They went after Trivy, and then let LiteLLM’s own automation do the rest.
Think about what a vulnerability scanner is allowed to do inside a build pipeline. It needs to read your dependencies, your container images, your filesystem, your configuration. Broad read access is not a misconfiguration in a security scanner. It is the entire product. So when a poisoned Trivy landed inside LiteLLM’s runner, it was already sitting exactly where an attacker would most want to be, with permissions nobody would flag as suspicious, harvesting the publishing tokens that let it sign the next stage of the attack as LiteLLM itself.
Every defensive instinct here points the wrong way. Pinning your scanner version would have helped, but teams are told to keep security tools on the latest release precisely so they catch the newest vulnerabilities. Verifying the package signature would not have helped at the LiteLLM stage, because the malicious releases were published from the genuine account with genuine tokens. The attack was designed to be indistinguishable from good practice.
What Was Actually Taken
The payload ran on every Python invocation, without needing to be imported, which meant it fired on essentially anything the affected environment did. Researchers who analyzed the captured data found a comprehensive sweep of whatever the runner could see:
- Cloud credentials for AWS, Google Cloud and Azure, including secret access keys
- SSH keys and Kubernetes tokens, which extend access from build systems into clusters and servers
- CI/CD secrets and environment variables, the catch-all bucket where most organizations store everything else
- Package publishing credentials, meaning the same trick could be replayed against other projects
- SaaS tokens including Salesforce client secrets, Slack signing secrets and GitLab identities
- AI provider API keys, which are both expensive to have stolen and rarely rate-limited by default
Organizations identified in the exposure data include Nvidia, AWS, Microsoft, Samsung, Cisco, Salesforce, ServiceNow, Siemens, Volkswagen, FedEx, S&P Global, John Deere, Epic Games, Orange, TomTom, BT Group and Accenture Federal Services. Estimates of the total organizational count vary by researcher, from roughly 2,100 in one analysis to more than 2,500 in CloudSEK’s, which is normal when different teams use different confidence thresholds for attributing a leaked secret to a company.
Why AI Infrastructure Keeps Being the Soft Target
LiteLLM is a gateway that lets applications talk to many different AI model providers through one interface. That job description is why it ended up in 434,000 pipelines: as companies bolted AI features onto everything over the past two years, they needed a layer to manage keys, routing and fallbacks between providers. It is glue code, and glue code spreads fast because nobody thinks hard about it.
It is also, unavoidably, the component that holds every AI provider key the organization owns.
That combination, ubiquitous plus highly privileged plus adopted faster than it was reviewed, describes a lot of the AI tooling layer right now. We have already watched the same structural weakness show up from the other direction, when frontier models broke out of their own safety-test sandboxes four times in three weeks and reached real production systems. Different mechanism, same root cause: the infrastructure around AI has been built at a speed the security engineering never matched.
And the offensive side keeps getting cheaper. Only this week, researchers disclosed that a zero-click Zoom exploit was found and weaponized in under 24 hours using fewer than 20 AI prompts. Supply chain attacks like this one still require patience and planning. The exploitation of the credentials now sitting in that 153GB archive does not.
What To Do If You Might Be Affected
- Check your March build logs for LiteLLM 1.82.7 or 1.82.8. Direct dependency or transitive, it does not matter. If either version was installed, treat the environment as compromised.
- Rotate on the assumption of total exposure, not partial. The payload swept environment variables indiscriminately. Anything your runner could read in March should be considered read. That includes secrets you have since moved elsewhere.
- Rotate publishing tokens first. That is the credential type that turns your organization into the next stage of somebody else’s supply chain attack, exactly as it did to LiteLLM.
- Audit for use, not just exposure. Rotation stops future abuse. It tells you nothing about what happened between March and now. Pull cloud access logs, check for unfamiliar API calls, look at AI provider billing for spikes you cannot explain.
- Pin and isolate your security tooling. The uncomfortable lesson is that scanners deserve the same supply chain scrutiny as application dependencies, and arguably more, given how much they are allowed to read.
The Bottom Line
Forty minutes of exposure on a package index turned into 153GB of other people’s secrets. No zero-day was required, no employee clicked anything, and every organization affected was doing something a security team would normally recommend: running an up-to-date vulnerability scanner in an automated build pipeline. The attackers simply worked out that in a modern software stack, the fastest route into thousands of companies is not through any of them. It is through the small, boring, deeply trusted thing they all install without thinking about it.
