Z.ai's Open Model Got Too Good at Hacking. It Delayed It
The LiteLLM Breach Just Hit 2,500 AI Tool Stacks
On August 11, CloudSEK published the first full accounting of a supply-chain compromise that’s been quietly weaponizable since March: LiteLLM, the open-source AI gateway that routes calls to more than 100 LLM providers from a single unified API, shipped two backdoored releases to PyPI after attackers hijacked the security scanner sitting inside its own build pipeline. CloudSEK’s number is blunt — 2,500+ companies and roughly 434,000 CI/CD pipelines potentially exposed. Hudson Rock’s independent analysis of the leaked data lands in the same neighborhood. Neither figure is a worst-case estimate. Both are read off an actual 153GB archive of what got stolen.
If you’ve never heard of LiteLLM, that’s sort of the point. It’s plumbing, not a product anyone puts on a slide. Engineering teams drop it in so their app can call OpenAI, Anthropic, Google, Bedrock, and a hundred other providers through one interface instead of maintaining a dozen separate SDKs. That makes it exactly the kind of dependency nobody audits — until it turns out to be the reason your AWS keys and your Anthropic API key left the building through the same hole.
Quick Summary: What Happened
Detail Info Disclosed August 11, 2026, by CloudSEK Initial compromise March 19–24, 2026 Tracked as CVE-2026-33634 Attacker Threat group “Team PCP” Entry point Trivy, the open-source scanner Aqua Security maintains, compromised via a leaked token that had been rotated but never fully revoked Payload Backdoored LiteLLM releases 1.82.7 and 1.82.8, published to PyPI and live for roughly 40 minutes before removal Scope 2,500+ companies, ~434,000 CI/CD pipelines, per CloudSEK; 2,488 corporate domains confirmed via a 153GB leaked archive, per Hudson Rock Government response FBI FLASH advisory FLASH-20260702-01, issued July 2, warning stolen credentials remain usable long after the intrusion Bottom line: A single unrevoked token from an unrelated prior incident cascaded through a scanner, a build system, and a package registry to expose credentials at thousands of companies — and the FBI says the danger isn’t over just because the packages are gone.
What Actually Happened
Start with the root cause, because it’s almost insultingly small for the size of the blast radius. Trivy, Aqua Security’s widely used open-source vulnerability scanner, had suffered an earlier, separate security incident. The response rotated a compromised authentication token. It didn’t fully revoke it. On March 19, Team PCP used that residual access to force-push malicious commits across dozens of Trivy’s GitHub release tags — The Hacker News reported 75 hijacked tags in the trivy-action repository alone — turning a trusted security tool into a credential stealer without publishing a single new release that would have drawn scrutiny.
Five days later, on March 24, LiteLLM’s own build process did what a huge number of CI pipelines do without thinking twice about it: it pulled Trivy straight from the source, unpinned to a specific verified version. The compromised scanner ran inside LiteLLM’s GitHub Actions environment, read the runner’s memory, and exfiltrated LiteLLM’s PyPI publishing token. Team PCP used that token to push two backdoored releases — versions 1.82.7 and 1.82.8 — directly to PyPI. They stayed live for about 40 minutes before the LiteLLM team caught and pulled them. Forty minutes doesn’t sound like much until you remember LiteLLM was pulling tens of millions of downloads a month at the time.
What Did the Malicious LiteLLM Packages Actually Steal?
- Cloud credentials — AWS, Azure, and GCP secrets present in the CI environment.
- AI provider API keys — OpenAI, Anthropic, Google, Cohere, and other keys LiteLLM was configured to route through.
- Source control access — GitHub tokens and SSH keys tied to the pipeline.
- Kubernetes and infrastructure secrets — cluster tokens and configuration data exposed to the build.
- Database credentials and environment variables — anything sitting in the runner’s environment at build time.
That list is the reason this stopped being a “LiteLLM problem” within days. A build pipeline that touches an AI gateway also touches everything else that pipeline is allowed to touch, and CI runners are typically allowed to touch quite a lot.
The Scope: 2,500 Companies, 434,000 Pipelines
CloudSEK’s August 11 disclosure is the first attempt to size the damage rather than just describe the mechanism, and the number is large enough that “supply chain attack” undersells it. CloudSEK maps the exposure at 2,500+ companies and roughly 434,000 CI/CD pipelines — the automated build-and-deploy workflows that would have pulled the poisoned package during that 40-minute window or run it from a cached copy afterward.
Hudson Rock ran a separate analysis and landed close to the same place from a different angle: a 153GB leaked data archive containing 433,909 files, which Hudson Rock attributes to 2,488 distinct corporate domains once it filtered down to 118,829 identifiable CI runner dumps. Two firms, two methodologies, roughly the same headcount. That convergence is what makes this disclosure different from an inflated vendor press release — it’s independently corroborated at the domain level.
High-confidence organizations named across CloudSEK’s and Hudson Rock’s reporting include NVIDIA, AWS, Cisco, Salesforce, Siemens, Samsung, S&P Global, ServiceNow, Deloitte, Vodafone, FedEx, Volkswagen, Thales, and X Corp. Being on that list doesn’t mean any of those companies had a confirmed breach beyond credential exposure in a CI runner — it means a runner tied to their domain touched the poisoned package during the exposure window. Whether that credential ever got used is a separate, harder question, and it’s exactly the one the FBI is warning about.
Why This Matters
The FBI’s FLASH advisory, issued July 2 — a full month before CloudSEK’s public sizing — is the detail that keeps this from being a closed incident. Stolen secrets don’t expire when a vendor patches the bug that let them leak. The advisory specifically warns that credentials harvested in the Trivy-LiteLLM cascade remain viable for future attacks, meaning an org that rotated its keys in April but missed one service account is still exposed in August, and will still be exposed in whatever month someone finally gets around to using that particular key.
That’s also why the domain-checking portals both firms shipped alongside their reports matter more than the headline numbers. CloudSEK’s exposure checker and Hudson Rock’s Cavalier platform both let an organization query its own domain against the leaked dataset — the difference between “we think we might be on a list of 2,500” and “here’s the specific runner dump with our name on it.” If your org runs any CI/CD pipeline that could plausibly have touched LiteLLM in March, that fifteen-minute lookup is a better use of time than debating whether you were affected.
What Are Your Options Now
Check both exposure portals, not just one. CloudSEK and Hudson Rock built their datasets independently, and the sizing numbers, while close, aren’t identical — a domain absent from one dataset can still show up in the other.
Rotate anything that touched a CI runner between March 19 and 24, 2026, on principle. If you can’t prove a specific key wasn’t exposed, the FBI’s advisory is telling you to treat it as exposed. That includes AI provider keys, which is the category this incident made newly urgent — most vendor-risk checklists for AI tools still focus on model behavior and data retention, not on whether the gateway routing your API calls got its build pipeline poisoned.
Pin your dependencies, especially security tooling. LiteLLM’s CI pulled Trivy unpinned from the package manager specifically because it’s a security scanner — the kind of tool teams reflexively trust to always be current rather than version-lock like anything else. That instinct is exactly backwards for a single point of failure sitting inside a build pipeline with broad credential access.
Revisit what your AI gateway is actually allowed to touch. If you’re running LiteLLM, any AI gateway, or a similar routing layer, this is a reasonable moment to check whether it holds broader credential scope than the task in front of it actually needs.
The Bigger Picture
Every AI vendor-risk story we’ve covered this summer has been about model behavior — Claude Mythos 5 fabricating identities under test conditions, OpenAI shipping a model that crosses its own “High” cyber threshold, Anthropic pushing Claude into banks and hospitals at the same moment its flagship model got its worst public scrutiny of the year. Those are real questions, but they all assume the risk lives inside the model. LiteLLM is a reminder that a huge amount of AI vendor risk lives in the unglamorous connective tissue between your app and the model — the gateway, the SDK, the scanner three layers upstream that nobody on your team has ever opened.
That’s a harder category to audit precisely because it’s boring. A procurement team can ask a model vendor about red-teaming and safety evals; asking whether an open-source dependency’s CI pipeline pins its security scanner isn’t a question most AI tool buyers know to ask, and most vendors don’t volunteer the answer unless something goes wrong. We’ve made a version of this argument before about self-hosting as a control for rogue-agent risk — moving execution onto infrastructure you actually control. The LiteLLM breach is the same lesson from the supply-chain side: the thing that broke wasn’t a model deciding to misbehave. It was one un-revoked credential, three tools deep, in a dependency almost nobody outside the engineering team had heard of.
Our Take
We don’t think LiteLLM did anything unusually careless here. Pulling a trusted security scanner unpinned from a package manager is standard practice across an enormous share of CI pipelines in 2026, not a LiteLLM-specific failure — which is precisely what should worry you if your org does the same thing. The actual failure sits one level up the chain, at Aqua Security’s incomplete token revocation after an earlier, separate incident. That’s the part worth internalizing: a security tool’s own supply chain is a supply chain too, and “we rotated the credential” isn’t the same claim as “we revoked it everywhere it could still work.”
What we’d push back on is any framing of this as a closed story now that CloudSEK and Hudson Rock have published their numbers. The FBI’s advisory predates both disclosures by a month and says the opposite — that harvested credentials stay dangerous well past the news cycle. If you’re an engineering leader whose first reaction to this piece is “we don’t use LiteLLM, so we’re fine,” the better question is whether you know, with the same confidence, what every scanner and gateway three layers deep in your own build pipeline is allowed to touch. Most teams don’t. That’s not a LiteLLM problem. That’s the actual state of AI tool supply chains right now.
Frequently Asked Questions
What is LiteLLM?
LiteLLM is an open-source AI gateway that gives applications a single, unified API to call more than 100 large language model providers — including OpenAI, Anthropic, Google, and Amazon Bedrock — instead of integrating each provider’s SDK separately. It’s widely used by engineering teams to consolidate LLM access, track spend, and load-balance across providers.
What is CVE-2026-33634?
CVE-2026-33634 tracks the compromise of Trivy, Aqua Security’s open-source vulnerability scanner, which Team PCP hijacked in March 2026 using a token that had been rotated but not fully revoked after an earlier, unrelated incident. That compromise is the root cause of the subsequent LiteLLM package backdoor.
How many companies were affected by the LiteLLM breach?
CloudSEK’s August 11 disclosure puts the number at 2,500+ companies and roughly 434,000 CI/CD pipelines. Hudson Rock’s independent analysis of a 153GB leaked data archive attributes exposure to 2,488 corporate domains, a closely aligned figure reached through a different methodology.
Which companies were named as high-confidence affected organizations?
Reporting from CloudSEK and Hudson Rock names NVIDIA, AWS, Cisco, Salesforce, Siemens, Samsung, S&P Global, ServiceNow, Deloitte, Vodafone, FedEx, Volkswagen, Thales, and X Corp among high-confidence exposures. Appearing on the list reflects that a CI runner tied to the organization’s domain was found in the leaked dataset, not a confirmed downstream breach.
Is the malicious LiteLLM package still available?
No. Versions 1.82.7 and 1.82.8 were live on PyPI for approximately 40 minutes before being pulled. The risk now isn’t the package itself — it’s whatever credentials were exfiltrated from CI runners that installed it during that window, which is what the FBI’s advisory addresses.
How do I check if my organization was exposed?
Both firms that analyzed the breach offer public lookup tools: CloudSEK’s exposure checker and Hudson Rock’s Cavalier platform. Query your organization’s domain against both, since the two datasets were built independently and don’t fully overlap.
Does the FBI advisory mean I need to act even if I never used LiteLLM directly?
Possibly, yes — if any dependency in your stack pulls LiteLLM transitively, or if your build tooling pulls Trivy the same unpinned way LiteLLM’s did. The FBI’s FLASH advisory warns that credentials harvested in this campaign remain usable well after the initial window, so indirect exposure through a shared dependency is worth ruling out rather than assuming away.
What should I do if my organization used LiteLLM 1.82.7 or 1.82.8 in March 2026?
Rotate every credential that was present in the CI environment during that window — cloud keys, AI provider API keys, source control tokens, database credentials — rather than trying to determine which specific ones were touched. The FBI’s advisory treats all of it as potentially compromised, and the cost of over-rotating is far lower than the cost of missing one.
Last updated: August 13, 2026. Sources: CloudSEK: AI Supply Chain Breach Disclosure · NVD: CVE-2026-33634 · FBI FLASH Advisory FLASH-20260702-01 · Hudson Rock analysis via CyberInsider · The Hacker News on the Trivy GitHub Actions compromise · Aqua Security incident update · LiteLLM official site.
Related reading: Frontier AI Models Now Face a Secret Government Review · OpenAI’s GPT-5.6-Cyber Crosses Its Own Risk Line · Anthropic Bets $1.5B on Claude in Banks and Hospitals · Claude Code Self-Hosted: The Fix for Rogue Agents? · MCP Hits 97M Installs: The Agent Standard Is Set
