# LiteLLM Breach: How Your AI Stack Got Backdoored in March > Source: > Published: 2026-08-24 02:09:15+00:00 In March 2026, a threat actor group called TeamPCP published two backdoored versions of LiteLLM to PyPI. They were live for roughly six hours. That was enough. This August, researchers finished mapping the full blast radius: more than 2,500 organizations, 434,000 CI/CD pipeline runs, cloud credentials harvested, SSH keys stolen, Kubernetes clusters potentially owned — and a persistent backdoor installed on any system that ran the compromised code. The story isn’t just what happened in March. It’s that your stack might still be exposed. ## What LiteLLM Is and Why Attackers Targeted It LiteLLM is the de facto standard for routing AI API calls across 140+ providers — OpenAI, Anthropic, Gemini, Mistral, local Ollama models — through a single OpenAI-compatible interface. It pulls roughly **95 million downloads per month** from PyPI. DSPy, CrewAI, Browser-Use, MLflow, LangChain, Mem0, Instructor, and a long list of MCP servers all depend on it. That ubiquity is exactly what made it a target. LiteLLM sits between your application and your cloud providers, holding API keys, database connection strings, and service credentials. Compromise it and you compromise everything downstream. TeamPCP understood this. Their campaign was not opportunistic — it was surgical. ## How a Security Scanner Became the Weapon TeamPCP did not attack LiteLLM directly. They attacked Trivy first. On March 19, they compromised Aqua Security’s [Trivy vulnerability scanner](https://snyk.io/blog/poisoned-security-scanner-backdooring-litellm/) — a tool widely trusted and run with broad CI/CD access — via an unrevoked automation token. Five days later, that compromised Trivy action ran inside LiteLLM’s own CI pipeline and exfiltrated LiteLLM’s PyPI publishing token. TeamPCP then used that token to publish versions 1.82.7 and 1.82.8 to PyPI with malicious code injected into a single file: `litellm/proxy/proxy_server.py` . The gap between 1.82.7 and 1.82.8 was thirteen minutes. The attacker was iterating in real time, adding a `.pth` injection vector in the second release to improve persistence. This was not a smash-and-grab. It was a professional operation. ## The Payload: Three Stages, Still Active If You Haven’t Rotated The malicious code deployed a three-stage attack once executed: **Credential harvest**— targeting 50+ secret categories: AWS, GCP, and Azure credentials, SSH private keys, Kubernetes cluster configs, CI/CD pipeline tokens, and cryptocurrency wallets**Lateral movement**— a Kubernetes toolkit capable of compromising entire clusters from a single compromised pod** Persistent backdoor**— a systemd service polling for additional attacker-controlled payloads, providing ongoing remote code execution even after the original package was removed The backdoor is the part that matters most right now. If your environment ran 1.82.7 or 1.82.8 and you haven’t rotated credentials, the window is still open. [CISA assigned this CVE-2026-33634](https://www.averlon.ai/blog/cve-2026-33634-trivy-and-litellm-supply-chain-attacks) with a CVSS score of 9.4 and added it to the Known Exploited Vulnerabilities catalog. ## The Hidden Danger: Transitive Dependencies Here’s the part most incident reports buried: the majority of affected developers never explicitly installed litellm. They installed something else. If you ran `pip install crewai` , `pip install dspy` , or `pip install browser-use` on March 24 without pinned versions, you pulled the compromised LiteLLM as a transitive dependency. LiteLLM flows as an indirect dependency into CrewAI, DSPy, Browser-Use, Mem0, Instructor, Guardrails, Agno, Camel-AI, and many MCP server implementations. Multiple projects filed security PRs on March 24 itself — but [automated pipelines had already pulled the package](https://securitylabs.datadoghq.com/articles/litellm-compromised-pypi-teampcp-supply-chain-campaign/). Check your requirements files and lock files now. The affected versions are **litellm 1.82.7 and 1.82.8**. ## What to Do If you used any of the affected frameworks around March 24, 2026, treat this as an active incident: - Search all environments for `litellm==1.82.7` or`litellm==1.82.8` - Rotate every secret that was accessible in those environments: cloud credentials (AWS, GCP, Azure), API keys for LLM providers, SSH keys, Kubernetes configs, CI/CD tokens - Clear build caches across GitHub Actions, GitLab CI, and Jenkins - If you use self-hosted runners, consider them compromised — rebuild from a clean image For longer-term hardening: pin every dependency with exact versions and cryptographic hashes (`pip install --require-hashes` ). Route PyPI traffic through a private artifact repository. Audit your transitive dependency tree — not just what’s in `requirements.txt` , but everything it pulls in. The [CloudSEK blast radius analysis](https://www.cloudsek.com/blog/ai-supply-chain-breach-2500-companies-434000-cicd-pipelines) has the full IOC list if you need to check your logs. ## AI Infra Is Now a Primary Attack Target This attack is a preview of what’s coming. As AI proxies, gateways, and LLM routing libraries become infrastructure — sitting between code and cloud, holding credentials for dozens of providers — they become the most attractive targets in the stack. TeamPCP ran five supply chain compromises in twelve days across March 2026: Trivy, Checkmarx KICS, LiteLLM, Telnyx, and Axios. The AI layer isn’t exempt from supply chain attacks. It’s becoming the primary focus. The industry spent years normalizing unpinned dependencies, automated trust in CI tooling, and zero scrutiny of transitive packages. That worked when the dependency tree was frontend libraries. It doesn’t work when your packages are routing credentials to every cloud service you run.