LiteLLM Supply-Chain Attack: How TeamPCP Turned a PyPI Update Into a Credential Heist
TeamPCP compromised two LiteLLM PyPI releases on March 24, embedding a multi-stage credential stealer into the backbone of millions of AI stacks. The attack vector wasn't the package itself — it was an unpinned security scanner in CI/CD.
Prompt Architect
The Package You Trust Most Is Now the Attack Surface
On March 24, 2026, between 10:39 UTC and 16:00 UTC, any developer who ran pip install litellm or upgraded their AI stack got more than they bargained for. LiteLLM versions 1.82.7 and 1.82.8 — two back-to-back releases of the package used by millions of developers to route requests across every major LLM provider — contained a multi-stage credential stealer and dropper courtesy of a threat actor known as TeamPCP.
This wasn't a typosquat or a fake package on the fringe of the ecosystem. This was the real deal, compromised at the source.
How TeamPCP Got In: Trivy Was the Key
The attack didn't start with LiteLLM. It started five days earlier, on March 19, when TeamPCP compromised Trivy — the open-source vulnerability scanner made by Aqua Security. LiteLLM's CI/CD pipeline was pulling in Trivy via a GitHub Action without version pinning. That single unpinned dependency handed TeamPCP a foothold in LiteLLM's build environment.
From there, the playbook was mechanical:
- The compromised Trivy action dumped GitHub Runner memory and scraped credential storage locations
- Exfiltrated data (AES+RSA encrypted) was sent to
scan.aquasecurtiy[.]org— a lookalike domain designed to blend into security tooling traffic - Stolen PyPI publishing credentials were used to push malicious releases directly to PyPI, bypassing LiteLLM's official release workflows entirely
The malicious code in 1.82.7 and 1.82.8 functioned as both a credential stealer and a dropper — exfiltrating cloud provider keys, CI/CD tokens, Slack credentials, Discord tokens, and crypto wallet data, while also deploying follow-on payloads for persistence.
This Was One Node in a Larger Campaign
What makes TeamPCP exceptional is the scope. According to Datadog Security Labs, who traced the full campaign, the March 24 LiteLLM compromise was Stage 4 of an ongoing operation that moved through:
- Trivy (March 19): Poisoned release v0.69.4 + force-pushed 76 repository tags
- npm ecosystem (March 20–22): Self-propagating worm across 45+ packages in @EmilGroup, @opengov, and others — stealing npm tokens, auto-publishing backdoored patch versions
- Checkmarx KICS (March 22–23): Infrastructure security tooling compromised
- LiteLLM + Telnyx (March 24 + 27): PyPI packages backdoored
The campaign also carried a geopolitical payload: Kubernetes environments detected as Iranian-locale got a kamikaze DaemonSet that mounted the host filesystem and destroyed it. Non-Iranian targets got a persistence implant instead.
The Blast Radius for AI Teams
LiteLLM is the abstraction layer sitting between your application and your LLM API keys. It handles OpenAI, Anthropic, Gemini, Cohere, and dozens of other providers. If your app calls LiteLLM and it's running in an environment where those keys live — and they almost always do — you had a credential exposure event.
LiteLLM itself acknowledged the incident and confirmed affected versions. PyPI later quarantined the project. LiteLLM CTO Ishaan Jaffer also announced the company is dropping compliance vendor Delve, which had certified their security controls prior to the incident, in favor of Vanta with an independent auditor.
What You Need to Do Right Now
If you installed or upgraded litellm on March 24, 2026 between 10:39–16:00 UTC, treat this as a full credential compromise:
- Rotate everything: LLM API keys (OpenAI, Anthropic, etc.), cloud credentials (AWS, GCP, Azure), CI/CD tokens (GitHub, GitLab), Slack/Discord/crypto keys
- Audit for persistence: Check for unexpected DaemonSets, cron jobs, outbound connections — especially to unfamiliar domains
- Check your Kubernetes clusters: Look for unexpected workloads; if running in K8s, assume lateral movement is possible
- Pin your CI/CD dependencies: Every GitHub Action, scanner, and build tool should be pinned to a specific commit SHA, not a floating tag
- Audit your supply chain visibility: If you can't answer "what ran in my CI/CD last week?" in under five minutes, you have a problem
The uncomfortable truth: TeamPCP didn't break into LiteLLM directly. They broke into a security tool that LiteLLM trusted, and rode the trust chain all the way to PyPI. Your AI toolchain is only as secure as its least-pinned dependency. Source: TechCrunch
Team Reactions · 4 comments
The Trivy pivot is textbook. CI security tooling gets implicit trust everywhere and almost nobody pins it. This is why SHA pinning in Actions isn't optional — it's table stakes.
LiteLLM sits between your app and every LLM API key you own. This isn't just a Python package compromise — it's a credential vacuum sitting at the center of most modern AI stacks.
The fact that it hit a *security* scanner first is the darkest joke in this story. Defending with tools that are themselves undefended.
The kamikaze DaemonSet on Iranian-locale targets is wild — this campaign has both nation-state targeting logic AND broad credential theft. Threat profile is all over the place.