TL;DR: A poisoned AI gateway package from March 2026 just resurfaced last week as something much bigger. Researchers at Hudson Rock and CloudSEK independently confirmed a 153GB archive of stolen credentials tied to thousands of companies, including AWS, Cisco, Salesforce, and Deloitte. The scale wasn’t visible until now, and it’s a case study in why AI infrastructure needs the same governance and third-party oversight as any other critical vendor.
What’s Happened
The LiteLLM package compromise happened back in March. What’s new is the scale, and it only came into focus late last week. Hudson Rock says it obtained and analyzed a 153GB archive of stolen data from the breach, publishing findings today that attribute 118,829 CI runner dumps to 2,488 corporate domains. CloudSEK, working from a separate dataset, published its own analysis on August 11 putting potential exposure at more than 2,500 organizations and 434,000 CI/CD pipelines. Neither figure existed publicly until this month. In March, the story was “a poisoned package got pulled.” Now it’s “here’s who was actually exposed.”
That distinction matters because the window to act is closing. Hudson Rock’s Alon Gal told researchers the archive “is not leaked anywhere at the moment and is not circulating widely,” calling it “a critical window of opportunity for companies to rotate keys and secrets before it eventually leaks, as is the natural cycle of a breach.” The FBI’s July 2026 FLASH advisory already warned that stolen credentials from this campaign would keep getting weaponized long after the original intrusion. Last week’s research confirms who’s on the list.
It also confirms that “we already rotated” isn’t always true. Security researcher Kevin Beaumont said one affected organization called the exposure “a nothingburger” because they’d rotated everything. He tested their credentials anyway. “Almost every one worked,” he reported.
How We Got Here
The underlying breach: in March 2026, the group TeamPCP compromised Trivy, a popular open-source security scanner, using a leaked automation token that had been rotated but never fully revoked. That gap let attackers force-push malicious code over Trivy’s published version tags for roughly 20 days. LiteLLM’s build pipeline installed Trivy automatically and unpinned, so the poisoned scanner gave attackers read access to steal LiteLLM’s own PyPI publishing tokens. With those, they pushed two poisoned releases to PyPI on March 24, live for roughly 40 minutes.
The payload didn’t need anyone to import LiteLLM. It shipped as a .pth file, which runs automatically when Python starts, so installing the package alone was enough to trigger it. It then harvested cloud credentials, SSH keys, Kubernetes tokens, and AI provider API keys from every runner it touched.
Why This Is an AI Governance Problem, Not Just a Security Incident
It’s tempting to file this under “another supply chain attack.” That undersells what happened. LiteLLM sits between an organization’s applications and its AI providers, which means it often holds the keys to the entire AI stack: model API keys, gateway configurations, and the pipelines that connect AI tools to production systems.
Beaumont put it bluntly: this is “a massive supply chain breach due to poor AI security, not because AI is the threat, but because teams can run circles around orgs obsessed with rushing out AI and poor DevOps security.” Gal put the scale the same way: “This magnitude pushes us into a completely new world regarding the type of response required from the cybersecurity industry.”
Teams adopted an AI gateway faster than they inventoried what it could touch. That’s an AI governance gap, and it’s exactly what shows up when AI adoption outpaces the risk program built to oversee it.
The Vendor Risk Nobody Was Tracking
Open-source dependencies rarely show up on a vendor risk register, but LiteLLM functioned exactly like a critical third party here: it had privileged access to sensitive systems, and its compromise created cascading impact across every organization that depended on it.
That’s concentration risk in its purest form. Thousands of unrelated companies inherited the same single point of failure, and most didn’t know it existed until last week’s research went looking. A vendor risk program that only tracks contracted vendors misses this entirely. One that maps every dependency, licensed or open source, to the systems it can reach would have flagged LiteLLM as a high-privilege connection point long before March.
What to Do Now
A few actions matter more than others while the window Gal described is still open:
- Rotate everything the affected process could touch, even if you already did once. Cloud credentials, repository tokens, and Kubernetes secrets accessible to that runner should be treated as compromised until independently verified.
- Inventory your AI infrastructure like you would any critical vendor. If you can’t list every AI gateway, agent, and model connection in your environment, you can’t assess what a compromise of any one of them would expose.
- Pin dependencies and CI tooling to verified hashes, not tags. A version tag can be force-pushed. A hash can’t.
- Build concentration risk into ongoing monitoring, not just onboarding. A dependency that looked low-risk at intake can become a shared point of failure as your stack grows.
None of this requires slowing AI adoption down. It requires the same discipline you’d apply to any vendor holding privileged access, applied to the AI layer before it becomes the entry point attackers count on.
LogicGate’s Risk Cloud® AI Governance solution helps risk and security teams accelerate AI adoption and innovation while still meeting the compliance bar set by regulators and internal policy. It catalogs every AI tool and vendor, including gateways like LiteLLM, and links them to risk so a compromise shows up as a mapped exposure, not a scramble. If you’re rethinking how AI infrastructure fits into your governance program, book a demo to see how Risk Cloud can help.
Frequently Asked Questions
In March 2026, the group TeamPCP compromised the open-source scanner Trivy through a leaked automation token, then used that access to steal LiteLLM’s PyPI publishing tokens and push two poisoned package releases live for about 40 minutes on March 24. Installing the package alone triggered a payload that harvested cloud credentials, SSH keys, Kubernetes tokens, and AI provider API keys.
Estimates vary by researcher. Hudson Rock attributes 118,829 CI runner dumps to 2,488 corporate domains. CloudSEK, working from a separate dataset, puts potential exposure at more than 2,500 organizations and 434,000 CI/CD pipelines. Both figures only became public in August 2026, five months after the original compromise.
Not according to Hudson Rock’s Alon Gal, who said the 153GB archive “is not leaked anywhere at the moment and is not circulating widely.” That’s a narrowing window, not a guarantee. Stolen credential archives tend to leak eventually as they change hands.
Possibly. Security researcher Kevin Beaumont tested credentials from an organization that considered itself unaffected because it had rotated everything, and said “almost every one worked.” Rotation only closes the gap if every touched credential gets independently verified, not just reissued.
Because it functioned like one. LiteLLM sat between applications and AI providers with privileged access to API keys, gateway configurations, and production pipelines. A vendor risk program that only tracks contracted vendors misses dependencies like this entirely.
Start by inventorying every AI gateway, agent, and model connection the way you would any critical vendor. If you can’t list what’s connected to your AI stack, you can’t assess what a compromise of any one piece would expose.
No. The gap wasn’t AI moving too fast, it was governance not moving with it. Applying the same discipline you’d use for any vendor with privileged access, at the AI layer, closes the gap without slowing adoption down.
