Is LiteLLM Safe to Use? What the March 2026 Supply Chain Attack Means for Your AI Stack

Is LiteLLM safe to use right now?

The short answer: The specific malicious packages from the March 2026 supply chain attack (versions 1.82.7 and 1.82.8 on PyPI) were quarantined within hours, and current releases are clean. If you installed either affected version, you should treat every credential on those systems as compromised and rotate immediately. The larger question for enterprise teams is not whether this one incident was contained. It was. The question is whether a community-maintained Python proxy is the right component to sit in the request path of every AI call your company makes, holding every model provider credential you own.

This post covers what happened, who was affected, how LiteLLM responded, and what the incident means for how enterprises should evaluate AI gateway infrastructure.

What happened in the LiteLLM supply chain attack?

On March 24, 2026, two versions of the litellm package on PyPI (1.82.7 and 1.82.8) were published containing malicious code. The threat actor, known as TeamPCP, did not break into LiteLLM’s codebase directly. They obtained a maintainer’s PyPI credentials through a prior compromise of Trivy, an open-source security scanner used in LiteLLM’s CI/CD pipeline (Snyk analysis).

The payload was a multi-stage credential stealer. According to Trend Micro’s research, it harvested environment variables, SSH keys, cloud provider credentials, and system information, encrypted them, and exfiltrated them to attacker-controlled infrastructure. It also installed a persistent backdoor that polled for second-stage payloads every 50 minutes, using a domain that abused a trusted security brand name to slip past DNS allowlists.

Two details made this incident unusually serious:

1. The code executed on every Python invocation. The malicious .pth file ran whenever the Python interpreter started in that environment, whether or not LiteLLM was ever imported (NHS England cyber alert CC-4761).
2. The blast radius was enormous. LiteLLM is downloaded roughly 3.4 million times per day and is present in a large share of cloud environments, which is exactly why it was targeted.

Who was affected, and who wasn’t?

The honest picture matters here, because overstating an incident helps nobody.

• Affected: Anyone who installed litellm 1.82.7 or 1.82.8 from PyPI during the roughly three-hour window before PyPI quarantined the packages, plus anyone whose CI/CD or transitive dependencies pulled those versions.
• Not affected: Users running the official LiteLLM Proxy Docker image, which pins dependencies and did not rely on the compromised packages, per LiteLLM’s own advisory.

If you were potentially exposed, removal is not enough. The malware established persistence. Affected teams should rotate every credential present on those systems, including provider API keys, cloud credentials, and SSH keys, and audit for second-stage payloads.

How did LiteLLM respond?

Credit where due: the response was credible. The LiteLLM team paused all releases, engaged Mandiant for forensic analysis, rebuilt their release pipeline with isolated environments and stronger gates, began signing all Docker images with cosign, and verified that no malicious code reached the main branch (LiteLLM security update).

This was a well-handled incident by a team that was itself a victim of an upstream compromise. The lesson is not “LiteLLM did something wrong.” The lesson is structural.

What does this incident reveal about AI gateway risk?

Your AI gateway is one of the highest-value targets in your entire stack, for three reasons:

1. It sits in the request path of every AI call your company makes. Prompts, responses, and any sensitive data flowing through them pass through it.
2. It holds every provider credential you own. OpenAI, Anthropic, Bedrock, Vertex: the gateway is where the keys live.
3. It runs everywhere. Developer laptops, CI pipelines, production clusters. A compromise propagates to all of them.

That means the security maturity of the gateway, and of the organization behind it, deserves the same scrutiny as the feature list. Questions enterprise teams should now be asking of any gateway, including ours:

• How is the supply chain secured? Are releases signed and reproducible? Is the build pipeline isolated?
• What is the provenance of the code? Is there a foundation, a security team, and a disclosure process behind it, or a small team moving fast?
• How quickly are credentials rotatable, and does the gateway architecture limit what a compromise can reach?
• Can the gateway run inside your own VPC or on-prem, so that a hosted compromise elsewhere doesn’t touch your traffic?

If the incident is a trigger to re-evaluate your gateway layer, see our LiteLLM migration guide for a step-by-step path that does not require rewriting applications.

How does Tetrate approach gateway supply chain security?

Tetrate Agent Router is built on Envoy AI Gateway, the first open-source AI gateway project backed by the CNCF, co-developed by Tetrate and Bloomberg. That foundation matters for supply chain posture in concrete ways:

• Foundation governance. The project lives under CNCF processes rather than a single vendor’s release account, with community-led development and no commercially gated code paths.
• Enterprise-hardened lineage. Envoy itself has spent a decade as critical infrastructure at the world’s largest enterprises, with the security scrutiny that attracts.
• Built and maintained by its co-creators. Tetrate ships enterprise builds of software it co-created and maintains upstream, rather than wrapping a third-party dependency it doesn’t control.
• Deployment in your perimeter. Agent Router Enterprise runs as a dedicated instance with data planes in your own AWS, Azure, or GCP VPC or on-prem, so your AI traffic and credentials stay inside your boundary.

For a broader view of how gateway categories compare after recent market shifts, including the Portkey acquisition, see our 2026 enterprise AI gateway comparison.

Frequently asked questions

Should I stop using LiteLLM because of the attack? Not necessarily because of this incident alone. Current versions are clean and the team responded well. But if LiteLLM has become load-bearing infrastructure for production AI at your organization, the incident is a reasonable trigger to re-evaluate whether your gateway layer matches the criticality of what now runs through it.

Which LiteLLM versions were compromised? Versions 1.82.7 and 1.82.8 on PyPI, published March 24, 2026, and quarantined the same day. Official Docker images were not affected.

What should I do if I installed an affected version? Uninstall, then treat every credential on the affected systems as compromised: rotate API keys, cloud credentials, and SSH keys, and audit for persistence mechanisms and second-stage payloads. Removal alone is insufficient.

Has any other AI gateway had a supply chain incident? This is the most significant publicly documented supply chain compromise of an AI gateway to date. The broader campaign (TeamPCP’s compromise of CI/CD tooling) affected multiple open-source projects, which is precisely why supply chain posture should now be a standard evaluation criterion for this category.

This is a sensitive topic for any team that was affected. If you’re assessing your exposure or rethinking your gateway architecture, talk to our team. Tetrate Agent Router is built on the CNCF-backed Envoy AI Gateway and deploys inside your own perimeter.

Sources

• LiteLLM security advisory (March 2026): docs.litellm.ai/blog/security-update-march-2026
• Snyk: “How a Poisoned Security Scanner Became the Key to Backdooring LiteLLM”
• Trend Micro Research: “Inside the LiteLLM Supply Chain Compromise”
• NHS England cyber alert CC-4761