LiteLLM Supply Chain Attack: How 97 Million Downloads Became a Security Nightmare

By
CTOL Editors - Wang Lang
1 min read

On March 24, 2026, attackers slipped two backdoored versions of litellm — v1.82.7 and v1.82.8 — onto PyPI, Python's central package registry. If you haven't heard of LiteLLM, you've almost certainly used something that depends on it. It's the universal proxy layer developers use to route traffic across 100+ AI providers — OpenAI, Anthropic, Google Gemini, AWS Bedrock, Azure — through a single interface. With 97 million monthly downloads, it's foundational plumbing for a massive chunk of the modern AI stack.

Once installed, the malware worked in three quiet stages. First, it harvested SSH private keys, cloud credentials, Kubernetes configs, API keys, database passwords, shell history, and CI/CD secrets. Then it encrypted everything using AES-256-CBC with a hardcoded RSA-4096 public key. Finally, it shipped the whole bundle off to a spoofed domain. Nobody caught it through clever detection — a bug in the code triggered a fork bomb that crashed a developer's machine. Without that accidental self-destruct, this could've run undetected for weeks.


This Wasn't a One-Off Hack

Here's where the story gets genuinely unsettling. This attack was the final move in a month-long, multi-ecosystem campaign by a threat actor called TeamPCP. The kill chain started in February with a compromise of Trivy, an open-source container security scanner maintained by Aqua Security. That breach was supposedly contained — but token rotation wasn't atomic. Attackers stayed inside the rotation window long enough to grab refreshed tokens before expiry.

That one operational failure cascaded across five ecosystems over four weeks. Trivy was re-compromised in March. Checkmarx's GitHub Action and KICS scanner got hijacked. Docker Hub repositories were defaced. Then, using a stolen PyPI publishing token, the attackers uploaded the malicious LiteLLM versions. They didn't break into LiteLLM at all. They walked in through a trusted side door — and nobody noticed.


The Blast Radius Is Wider Than You Think

Direct risk extended to every package with a transitive dependency on LiteLLM. DSPy, for example, declares litellm>=1.64.0 as a dependency — meaning any developer installing DSPy during the attack window was compromised without ever explicitly touching LiteLLM. CrewAI and numerous MCP servers carry similar exposure.

What makes this especially chilling is LiteLLM's architectural role. By design, it's a credential concentrator — the single layer where organizations aggregate API keys for every model provider they run. Compromising it doesn't mean stealing one key. It means stealing the entire keyring.


The Investment Signal

For investors, this incident reads as selectively bullish and broadly cautionary.

Who wins: Vendors monetizing artifact provenance, identity-based CI/CD, dependency governance, and runtime secret-use monitoring. PyPI's Trusted Publishing (OIDC-based, no long-lived tokens) and GitHub's SHA-pinned Actions represent the architecture of the next secure delivery generation. Companies building in supply chain security, cloud identity hardening, and runtime credential-abuse detection now have a compelling new reference case.

Who loses: Organizations running sprawling OSS/AI stacks with thin release controls, long-lived publishing tokens, and mutable CI/CD dependencies. The modern AI tooling stack has quietly centralized enormous blast radius into a handful of convenience abstractions — model gateways, eval SDKs, agent frameworks, MCP glue. LiteLLM is emblematic of that problem, not an exception to it.

The governance takeaway for any technical leadership team is clear: migrate PyPI publishing to OIDC Trusted Publishing, pin GitHub Actions to full commit SHAs, and architecturally isolate any tooling that aggregates cloud credentials. Treating package management as commodity plumbing is now a boardroom-level risk.


The Harder Lesson

This won't be remembered as a LiteLLM story. It'll be remembered as the moment the industry had to confront that AI middleware has become a high-value target — and that the same convenience abstractions that accelerated AI adoption have quietly become the most dangerous part of the stack. The attackers understood the secret density better than most defenders did. That asymmetry is the real threat.

not investment advice

Sources: https://x.com/karpathy/status/2036487306585268612

You May Also Like

This article is submitted by our user under the News Submission Rules and Guidelines. The cover photo is computer generated art for illustrative purposes only; not indicative of factual content. If you believe this article infringes upon copyright rights, please do not hesitate to report it by sending an email to us. Your vigilance and cooperation are invaluable in helping us maintain a respectful and legally compliant community.

Subscribe to our Newsletter

Get the latest in enterprise business and tech with exclusive peeks at our new offerings

We use cookies on our website to enable certain functions, to provide more relevant information to you and to optimize your experience on our website. Further information can be found in our Privacy Policy and our Terms of Service . Mandatory information can be found in the legal notice