The LiteLLM supply chain attack exposed why every open source AI gateway is a high-value target. How the backdoor worked, what got stolen, and what it means for gateway security.
Every API key your organization uses for LLMs, every cloud credential that provisions inference, every provider token that routes prompts to OpenAI or Anthropic or Google: an open source AI gateway holds all of them. That concentration is the point. It is also the reason attackers spent months building the infrastructure to compromise one.
On March 24, 2026, two backdoored versions of LiteLLM appeared on PyPI. The malicious packages harvested SSH keys, cloud credentials, LLM API keys, database passwords, and crypto wallets from every machine they touched. They were live for approximately 40 minutes before PyPI quarantined them. Forty minutes, on a package downloaded roughly 3.4 million times per day.
The attack did not exploit a vulnerability in LiteLLM's code. It exploited the position LiteLLM occupies in the AI stack. And that position, the open source AI gateway sitting at the intersection of every credential in your AI infrastructure, is exactly what made it worth attacking.
One of the most defining themes of 2025 was the rapid rise of the AI Gateway as a core piece of enterprise AI infrastructure. What started as an optional proxy layer, something teams assumed they could build in-house over a weekend, turned out to be a deeply complex control plane requiring security policies, governance, observability, and reliability at scale.
The adoption numbers tell the story. Roughly 10% of enterprises actively use an AI gateway today, and that figure is expected to grow to nearly 70% within three years. The trajectory turned gateways from "nice to have" into foundational infrastructure faster than most security teams could adapt.
That speed created a structural problem. Every open source AI gateway that went into production inherited the same risk profile: a single component holding centralized credentials for every LLM provider, every cloud environment, every downstream service. Compromise the gateway, and you compromise everything it connects to.
LiteLLM became the default. It acts as a unified API gateway for over 100 LLM providers and has 95 million monthly downloads on PyPI. It is integrated across virtually every major AI agent framework, MCP server, and LLM orchestration tool.
The reach extended beyond teams that chose it deliberately. If you work with AI, there is a good chance LiteLLM is somewhere in your dependency tree, even if you never installed it directly. That transitive presence is what made it the perfect supply chain target: attackers did not need victims to install the package on purpose. They just needed it to exist somewhere in the chain.
The attack chain started with Trivy, an open-source vulnerability scanner. In late February 2026, an actor exploited a misconfigured pull_request_target workflow in Trivy's CI to exfiltrate credentials. The stolen credentials included the token that LiteLLM's CI pipeline used to publish packages to PyPI.
This is the detail that matters: the security scanner, the tool defenders rely on to catch supply chain compromises, became the entry point for a supply chain compromise.
With legitimate publishing credentials in hand, the threat actor known as TeamPCP published backdoored versions 1.82.7 and 1.82.8 to PyPI on March 24, 2026. The campaign was not limited to one ecosystem. TeamPCP orchestrated one of the most sophisticated multi-ecosystem supply chain campaigns publicly documented to date, spanning PyPI, npm, Docker Hub, GitHub Actions, and OpenVSX in a single coordinated operation.
For a deeper timeline of the incident itself, see our breakdown of the LiteLLM supply chain attack.
The two malicious versions used different injection techniques.
Version 1.82.7 injected malicious code directly into proxy_server.py, the source file that runs when LiteLLM starts as a proxy. Standard code review could, in theory, catch it.
Version 1.82.8 took a different approach. It included a .pth file, litellm_init.pth, which executes on every Python process startup without requiring an import. No one needs to call import litellm. The payload runs the moment Python starts.
The .pth file passed all standard pip hash verification because the malicious content was published using legitimate credentials, not injected after the fact. Signature checks, hash validation, integrity verification: all green. The attacker walked through the front door with the maintainer's own keys.
The 1.82.8 version also contained a bug. The .pth launcher spawned a child Python process, but because .pth files trigger on every interpreter startup, the child re-triggered the same .pth, creating an exponential fork bomb that crashed the machine. The fork bomb was accidental. It was a bug in the malware, and it is what led to the attack's discovery.
The malicious versions deployed a three-stage payload:
The malware harvested SSH keys, cloud credentials, LLM API keys, .env files, database passwords, and crypto wallets from any machine it ran on, targeting over 50 categories of secrets.
Harvested credentials were sent to models.litellm.cloud, a domain registered one day before the attack to impersonate legitimate LiteLLM infrastructure.
The malware installed a persistent systemd backdoor that polled for additional payloads and included a Kubernetes lateral movement toolkit capable of compromising entire clusters.
This is the structural argument against open source AI gateways operating without an additional security layer. AI proxy services that concentrate API keys and cloud credentials become high-value collateral targets when supply chain attacks compromise upstream dependencies. The gateway's purpose, centralizing access, is exactly the property that makes it worth attacking.
The discovery was accidental. FutureSearch found it when LiteLLM was pulled in as a transitive dependency by an MCP plugin running inside Cursor. They never directly installed LiteLLM. The fork bomb crashed their machine, they investigated, and they found the backdoor.
What followed was unusual. After a GitHub issue was opened to disclose the attack, bots flooded it with comments and the issue was closed using the compromised maintainer account. The attacker used the same stolen credentials to suppress the disclosure.
There was one safe path. Customers running the official LiteLLM Proxy Docker image were not impacted because that deployment path pins dependencies in requirements.txt and does not rely on the compromised PyPI packages.
Anyone who ran pip install litellm without version pinning during the 40-minute window was at risk. Anyone whose CI/CD pipeline pulled the latest version automatically was at risk. Anyone whose transitive dependency tree included LiteLLM, even if they had never heard of it, was at risk.
LiteLLM's response included engaging Google's Mandiant security team and releasing a clean v1.83.0 via a new CI/CD pipeline with isolated environments and stronger security gates. Those are necessary steps. They are also reactive ones.
The incident forces a harder question about the open source AI gateway model itself. When a gateway centralizes credentials for every LLM provider and cloud service an organization uses, the blast radius of a single compromise extends to every system the gateway touches. Pinned dependencies help. Isolated CI/CD pipelines help. But the fundamental architecture, one component holding every key, remains the attack surface.
Teams evaluating open source AI gateways now have a decision to make. The category is growing fast (from 10% enterprise adoption toward 70%), and the credential aggregation problem is not going away. If anything, it intensifies as organizations add more providers, more models, and more agent frameworks.
The options are not binary. You can self-host with hardened infrastructure, use a managed gateway that isolates credentials by design, or layer additional security controls on top of whatever gateway you choose. Our comparison of LiteLLM alternatives covers the tradeoffs across the current landscape.
What you cannot do is treat your AI gateway as if it is just another proxy. It holds everything. The LiteLLM incident proved that attackers know this too.
SHIM is a managed AI gateway for native OpenAI, Anthropic, and Google APIs. It provides PII placeholder processing and request accounting without adding a self-hosted proxy package or semantic response cache.