The LiteLLM Supply Chain Attack: How a Compromised AI Gateway Exposed 2,500+ Companies

If your AI stack routes model calls through LiteLLM, this is not an abstract security story. LiteLLM is one of the most widely used open-source AI gateways on the internet — a proxy layer that lets a Python or FastAPI backend call OpenAI, Anthropic, Google, or dozens of other providers through one consistent interface. In March 2026, a threat actor group tracked as TeamPCP compromised it. Security research firm CloudSEK published the full picture on 11 August, and the numbers are the kind that get a supply chain incident called the largest of its kind this year: more than 2,500 organizations and an estimated 434,000 CI/CD pipelines potentially touched, going back five months before anyone outside the attackers knew it had happened.

This wasn't a case of someone finding a bug in LiteLLM's code. It was worse, in a specific way that matters for how you think about your own dependency tree.

How the attack actually worked

TeamPCP didn't target LiteLLM directly first. According to CloudSEK's research, the group compromised Trivy, a widely used open-source vulnerability scanner, along with several other developer tools including KICS and the Telnyx Python SDK. LiteLLM's own continuous integration pipeline pulled Trivy unpinned — installed straight from the system package manager rather than locked to a known-good, hash-verified version. When Trivy was compromised, the poisoned version flowed automatically into LiteLLM's next build. That build produced and published two trojanized releases, versions 1.82.7 and 1.82.8, to PyPI.

The payload itself was quietly effective. It shipped as a .pth file, a Python mechanism that executes automatically the moment the interpreter starts — no import litellm required, no application code needed to run the attacker's logic. Once active on a CI runner, it searched for anything that looked like a credential: environment variables, local config files, process memory, cloud instance metadata endpoints on AWS, GCP, and Azure, and mounted Kubernetes service-account tokens. Everything a build pipeline typically has lying around to do its job.

PyPI's own security tooling caught and quarantined the malicious packages within roughly 40 minutes. That sounds like a fast catch, and it was. It's also almost beside the point: any credential the payload harvested during that window stays valid, and usable, long after the package itself is gone.

What was actually exposed

CloudSEK's reconstruction lists cloud provider keys, SSH keys, Kubernetes secrets, CI/CD platform secrets, source-repository and package-publishing credentials, environment variables, and AI provider API keys among what the payload could reach. That last category is the one worth sitting with: an AI gateway compromise doesn't just leak your cloud infrastructure, it leaks the API keys for whichever frontier model providers your agents are calling, on whatever billing and access tier you've provisioned them.

The FBI underlined the shelf life of that exposure directly. A FLASH advisory issued 2 July 2026, before CloudSEK's public writeup, warned that credentials harvested through this kind of software supply chain compromise remain weaponizable for weeks or months unless they are actively rotated — not automatically invalidated when the malicious package is pulled from a registry. A short exposure window on PyPI does not translate into a short exposure window for whatever that package touched.

Why this fits a pattern, not a one-off

We've written before about AI agents becoming the path an attacker reaches through rather than the thing being attacked directly, from the Mythos-adjacent incidents last spring to JADEPUFFER, the first ransomware operation run end-to-end by an autonomous agent, to this week's containment failures at Anthropic and OpenAI. The LiteLLM attack is a different mechanism from all three, but the same underlying failure we flagged in our piece on the shadow AI agent governance gap: most organizations cannot currently answer "what does our AI infrastructure actually depend on, and what can each of those dependencies reach." An unpinned scanner in a CI pipeline is exactly the kind of dependency nobody puts on a risk register, because it isn't the AI system — it's the thing that builds the thing that builds the AI system.

That distance is precisely why it worked. Trivy is a security tool. Teams install it, and trust it, specifically because it's supposed to catch vulnerabilities, not become one.

What to check in your own stack this week

If you run LiteLLM, or any AI gateway, in a CI/CD pipeline, a few concrete steps are worth doing regardless of whether you can confirm you pulled the affected versions:

• Confirm which LiteLLM version your builds actually installed during the affected window, not just what your lockfile says today — a .pth-based payload can persist in a cached environment even after you upgrade past it.
• Pin your build tooling, not just your application dependencies. If Trivy, or any scanner, linter, or CI utility, is installed unpinned from a system package manager, it's an unaudited input to every build that runs after it updates.
• Rotate, don't just check. Cloud keys, SSH keys, Kubernetes service-account tokens, and AI provider API keys that touched an affected CI runner should be rotated on the assumption they were read, not on confirmation that they were misused.
• Scope AI provider keys per service, so a compromised build pipeline can't reach every model your organization has access to through one shared credential.

The takeaway

The story here isn't that LiteLLM had a vulnerability — plenty of software does. It's that a compromise three tools removed from the AI gateway itself turned into ecosystem-wide credential exposure, because the trust chain between "security scanner," "build pipeline," and "published package" had no verification step anywhere along it. For any business running AI agents against real infrastructure, the lesson generalizes past this one incident: your AI stack's actual attack surface is your entire build and deployment chain, not just the model calls at the end of it.

If you want a clear audit of what your AI infrastructure actually depends on, and where a compromise three steps removed could still reach your credentials, get in touch with our team. Better to map the chain before someone else finds the weak link in it.

Sources

• 2,500+ Companies and 434,000 CI/CD Pipelines Exposed in the Largest AI Supply Chain Breach of 2026 — CloudSEK
• Malicious LiteLLM Releases Tied to Trivy Hack May Have Exposed 2,100+ Organizations — The Hacker News
• Over 2,500 Organizations Impacted by LiteLLM Supply Chain Attack — SecurityWeek
• LiteLLM Attack Affected 2,500 Companies, 434,000 CI/CD Pipelines: CloudSEK — DevOps.com
• Compromised litellm PyPI Package Exposes AI Systems — Sonatype
• Supply Chain Attack Exposes 2,500+ Companies in Largest AI Infrastructure Breach of 2026 So Far — CX Today
• FLASH-20260702-01 — Federal Bureau of Investigation