LiteLLM Supply Chain Attack: What It Means for Your API Keys

Key Takeaways

• Backdoored LiteLLM versions 1.82.7–1.82.8 harvested API keys, SSH credentials, and cloud secrets for ~40 minutes on March 24, 2026 (LiteLLM Official Blog, 2026)
• The attack exploited Aqua Security's Trivy vulnerability scanner — a security tool became the attack vector
• Docker image users were unaffected; only pip installs were compromised
• Rotate all secrets if you installed LiteLLM via pip between March 24–30, 2026

A supply chain attack on an LLM proxy occurs when an attacker compromises a dependency in the proxy's software supply chain — such as a PyPI package, a CI/CD tool, or a Docker base image — to inject malicious code that intercepts API keys and cloud credentials passing through the proxy. In March 2026, this is exactly what happened to LiteLLM, the most widely used open-source LLM proxy. If you're evaluating LLM proxy alternatives, this incident should reshape how you think about the hidden costs of AI infrastructure.

What Happened

On March 24, 2026, at 10:39 UTC, the threat group TeamPCP published backdoored versions 1.82.7 and 1.82.8 of LiteLLM to PyPI. LiteLLM is the most widely used open-source LLM proxy, with 95 million monthly PyPI downloads and 51,100 GitHub stars (Endor Labs, March 2026; GitHub, June 2026).

The malicious packages were live for approximately 40 minutes before PyPI quarantined them (LiteLLM Official Blog, March 2026).

Key facts:

• Attack vector: TeamPCP first compromised Aqua Security's Trivy vulnerability scanner, which LiteLLM used in its CI/CD pipeline. Through Trivy, they stole PyPI publishing credentials (Snyk, March 2026).
• Payload: A malicious .pth file that auto-executed on every Python process. Three stages: credential harvesting (SSH keys, AWS/GCP/Azure secrets, Kubernetes tokens, crypto wallets), lateral movement across Kubernetes clusters, and a persistent systemd backdoor (Trend Micro, March 2026).
• Clean release: Version 1.83.0 shipped on March 30 via a rebuilt CI/CD v2 pipeline with isolated build environments.
• Docker users were safe. Docker images pin dependencies in requirements.txt and did not pull the compromised PyPI packages.

Why Does the LiteLLM Attack Matter?

In 2025, Sonatype tracked 454,600 malicious open-source packages — a 75% year-over-year increase (Sonatype, 2025). The LiteLLM incident isn't an outlier. It's the pattern accelerating.

What makes this attack distinctive is the trust-chain inversion. TeamPCP didn't target LiteLLM directly. They compromised Trivy, a vulnerability scanner made by Aqua Security — the exact kind of tool teams run to protect themselves from supply chain attacks. The scanner became the entry point.

This wasn't a one-off, either. In 2026, Datadog Security Labs documented that TeamPCP's campaign spans five ecosystems: GitHub Actions, Docker Hub, npm, OpenVSX, and PyPI. They also compromised Checkmarx's KICS scanner using the same playbook (Datadog Security Labs, March 2026; Kaspersky, March 2026).

The pace is getting worse. In 2026 H1 alone, Phoenix Security indexed 37 supply chain campaigns targeting 497 malicious packages — 4.5 times the package volume of all of 2025 (Phoenix Security, 2026).

And the fallout didn't end with the backdoor. Within weeks, security researchers disclosed two additional LiteLLM vulnerabilities: CVE-2026-42208, a pre-authentication SQL injection affecting v1.81.16 through v1.83.6 (Sysdig, 2026), and CVE-2026-42271, a command injection vulnerability added to CISA's Known Exploited Vulnerabilities catalog (SecurityWeek, 2026). The deeper audit triggered by the supply chain attack surfaced issues that had been sitting in the codebase.

How Does This Affect Teams Using LLM Proxies?

For teams routing LLM calls through open-source proxies, the immediate risk goes beyond LiteLLM itself. Here's what changed.

Your API keys may have been exfiltrated

If anyone on your team ran pip install litellm or pip install --upgrade litellm on March 24, 2026, the malicious .pth file auto-executed on every subsequent Python process in that environment. It harvested environment variables — which is where most teams store their OpenAI, Anthropic, and cloud provider API keys.

A single compromised CI/CD runner could have leaked every secret it had access to: LLM API keys, database credentials, cloud IAM tokens, and SSH keys.

The blast radius extends beyond the proxy

The payload didn't just steal credentials. It moved laterally through Kubernetes clusters and installed a persistent systemd backdoor. Even if you've since upgraded to v1.83.0, the backdoor may still be active on systems that ran the compromised version. A version upgrade doesn't undo a rootkit.

Self-hosted proxies inherit their dependency tree's risk

This incident exposes a structural problem: self-hosted open-source LLM proxies put PyPI (or npm, or Docker Hub) in the trust chain for every single LLM API call. LiteLLM has hundreds of transitive dependencies. Each one is a potential entry point. Every pip install --upgrade is a decision to trust the entire upstream supply chain with your most valuable secrets.

Docker deployments mitigate this partially — they pin dependencies at image build time, which is why Docker users were unaffected here. But Docker doesn't eliminate the risk. It shifts it to image build time, where a compromised base image or a docker pull at the wrong moment has the same effect.

The alternative is a managed proxy that doesn't run in your environment at all. When the proxy is an external API endpoint, there's no PyPI in your trust chain, no .pth files on your servers, and no transitive dependencies to audit. Your LLM calls route through HTTPS — the same trust model as calling OpenAI directly. Tokonomics works this way: a managed HTTP proxy with no client-side dependencies.

What Should You Do Now?

Here are four steps to take in response to this incident, ordered by urgency.

1. Today — audit your exposure. Check pip install logs and lock files for LiteLLM versions 1.82.7 or 1.82.8. LiteLLM published detection scripts on March 25. Run them on every environment where LiteLLM was installed.

2. This week — rotate compromised secrets. If you installed either affected version, assume all environment variables in that context were exfiltrated. Rotate API keys, SSH keys, cloud IAM credentials, and database passwords. Check for the systemd backdoor (look for .pth files in your Python site-packages).

3. This month — harden your dependency pipeline. Pin exact versions in requirements files. Enable hash verification with pip install --require-hashes. Use a dependency firewall like Socket or Snyk that detects behavioral anomalies in new package versions before they reach your environments. Consider whether a managed proxy approach reduces your attack surface compared to self-hosted alternatives.

4. Ongoing — monitor the threat landscape. Subscribe to PyPI security advisories and the CISA KEV catalog. CVE-2026-42271 was actively exploited within 36 hours of disclosure — speed matters.

Do NOT:

• Assume you're safe because you use Docker. This time, Docker users were unaffected. The next attack vector might be a compromised base image or a build-time dependency pull.
• Panic-migrate off LiteLLM without auditing first. Version 1.83.0 addressed this specific compromise with a rebuilt CI/CD pipeline. The question isn't whether LiteLLM is safe now — it's whether your systems that ran the compromised version have been cleaned.

The Bigger Picture: Why LLM Infrastructure Is the Next Target

The LiteLLM incident fits a pattern that's been building since 2023. Attackers are moving up the value chain: from targeting general-purpose packages to targeting infrastructure that handles high-value credentials.

LLM proxies are uniquely attractive targets. They sit between applications and API providers, routing requests that carry API keys worth thousands of dollars per month. A compromised proxy doesn't just steal one credential — it intercepts a continuous stream of them.

Consider the attack surface: LiteLLM (95M monthly downloads), LangChain (30M+), CrewAI, Haystack, and dozens of smaller frameworks all occupy this same trust position. They handle credentials on every call. They auto-update through package managers. And they're maintained by small teams with limited security budgets. It's not a question of whether similar attacks will target other AI frameworks — it's when.

The broader lesson? Any dependency in the path between your application and your LLM provider is a liability. The fewer moving parts, the smaller the attack surface. Whether that means pinning dependencies aggressively, deploying via Docker with verified images, or switching to a managed proxy that eliminates client-side dependencies entirely — the goal is the same: minimize the code that touches your secrets. For teams ready to act, setting up hard spending caps is the fastest way to limit blast radius if credentials are ever compromised.

Frequently Asked Questions

Was every LiteLLM user affected by the supply chain attack?

No. Only users who installed LiteLLM via pip between March 24 and March 30, 2026, were exposed to versions 1.82.7 or 1.82.8. Docker image users were unaffected because Docker pins dependencies in requirements.txt at build time, bypassing PyPI for runtime installs (LiteLLM Official Blog, March 2026).

What data did the LiteLLM malware steal?

The three-stage payload harvested environment variables (API keys for OpenAI, Anthropic, AWS, GCP, Azure), SSH private keys, Kubernetes service account tokens, and cryptocurrency wallet data. It also performed lateral movement across Kubernetes clusters and installed a persistent systemd backdoor via a .pth file (Trend Micro, March 2026).

How can I check if my systems were compromised?

Check your pip install logs and lock files for LiteLLM 1.82.7 or 1.82.8. LiteLLM published detection scripts on March 25, 2026. Search for unexpected .pth files in Python site-packages directories and check for unknown systemd services. If you find evidence of compromise, rotate every secret that was accessible in that environment.

Is LiteLLM safe to use now?

Version 1.83.0, released March 30, 2026, was built on a new CI/CD v2 pipeline with isolated environments. The supply chain vector that enabled this attack has been closed. However, two additional CVEs (CVE-2026-42208 and CVE-2026-42271) were disclosed in the weeks following, so ensure you're running the latest patched version.

How does a managed proxy reduce supply chain risk compared to self-hosted?

A managed proxy runs as an external HTTP endpoint. Your application sends requests over HTTPS — the same trust model as calling OpenAI directly. There are no pip dependencies, no .pth files, and no transitive dependency tree in your environment. The supply chain risk shifts to the managed provider, who bears the responsibility of securing their infrastructure.

Sources

All sources retrieved 2026-06-22.

• Security Update — March 2026 — LiteLLM Official Blog, March 2026, retrieved 2026-06-22
• Poisoned Security Scanner Backdooring LiteLLM — Snyk, March 2026, retrieved 2026-06-22
• TeamPCP Isn't Done — Endor Labs, March 2026, retrieved 2026-06-22
• LiteLLM Compromised: TeamPCP Supply Chain Campaign — Datadog Security Labs, March 2026, retrieved 2026-06-22
• Inside the LiteLLM Supply Chain Compromise — Trend Micro, March 2026, retrieved 2026-06-22
• Critical Supply Chain Attack: Trivy, LiteLLM, Checkmarx — Kaspersky, March 2026, retrieved 2026-06-22
• Open Source Malware Grows 75% — Sonatype, 2025, retrieved 2026-06-22
• Accelerating Supply Chain Attacks: npm, PyPI, VSX — Phoenix Security, 2026, retrieved 2026-06-22
• CVE-2026-42208: SQL Injection in LiteLLM — Sysdig, 2026, retrieved 2026-06-22
• Fresh LiteLLM Vulnerability Exploited Shortly After Disclosure — SecurityWeek, 2026, retrieved 2026-06-22
• BerriAI/litellm Repository — GitHub, June 2026, retrieved 2026-06-22