Is LiteLLM Safe to Use? What the Supply Chain Attack, the 2026 CVEs and the Safe Version Floor Actually Mean

LiteLLM is safe to run today on version 1.84.0 or later, behind a reverse proxy that normalizes the Host header, with management routes off the public internet and provider keys held somewhere other than a shared environment file. That is a genuine yes, not a hedged one.

The harder question is the one most teams are actually asking when they type this, and it is not about today. It is: did the March incident touch us, and would we know? Those are different questions with different answers, and conflating them is how organizations ended up rotating nothing after a credential stealer ran in their build environment.

The short version, in a table

Find your row before reading anything else.

Rows three and four are where the real money is, and they are the rows teams skip because the fix produces no visible artifact.

What actually happened in March 2026

On March 24, 2026, two malicious LiteLLM releases went up on PyPI. LiteLLM's own incident write-up states that "the compromised PyPI packages were litellm==1.82.7 and litellm==1.82.8" and that they "were live on March 24, 2026 from 10:39 UTC for about 40 minutes before being quarantined by PyPI."

Forty minutes is a short window for a human and an eternity for a build system. LiteLLM was seeing roughly 3.4 million PyPI downloads a day at that point. SecurityWeek reported that more than 2,500 organizations were affected.

The payload was not a proof of concept. It collected environment variables, SSH keys, cloud provider credentials for AWS, GCP and Azure, Kubernetes tokens and database passwords, then sent them to models.litellm.cloud, a domain LiteLLM notes is not theirs. Datadog Security Labs, which tracked the campaign across multiple packages, found that version 1.82.8 shipped a .pth file that "executes automatically when the Python interpreter starts." That detail is the one worth internalizing: with 1.82.8 you did not need to import LiteLLM, or run the proxy, or even use the library. Any Python process in that environment triggered it. Datadog also documented persistence installed via a systemd unit and the implant polling an attacker-controlled domain for further instructions.

The entry point deserves its own paragraph. LiteLLM believes "the compromise originated from the Trivy dependency used in our CI/CD security scanning workflow," and that "the attacker bypassed official CI/CD workflows and uploaded malicious packages directly to PyPI." A vulnerability scanner was the way in to a release pipeline. If you maintain a mental model where security tooling is the trusted part of the build, that model is now out of date.

How to tell whether you were exposed

Most teams answer this from memory, which is worthless, because the exposure window was 40 minutes on a Tuesday five months ago and nobody remembers what CI did that morning. Answer it from evidence:

1. Grep every lockfile and manifest in every repository for 1.82.7 and 1.82.8, including branches that were merged and deleted. A floating version range is the risk here, not a pin.
2. Search container image history. Any image layer built between roughly 10:39 and 11:20 UTC on March 24, 2026 that ran a pip install resolving LiteLLM without a hash is a candidate, and those images may still be running.
3. Search CI logs for install output naming either version. Retention may have expired, in which case treat the result as unknown rather than negative.
4. Look for litellm_init.pth on any host, image or developer laptop that installed in that window. LiteLLM named this artifact specifically in its guidance.
5. Check for the persistence path Datadog documented at ~/.config/sysmon/sysmon.py and any unexpected systemd unit of that name.

Then look for the consequence rather than the cause. Stolen cloud credentials rarely announce themselves in a log; they announce themselves on the invoice, usually as compute in a region your team does not use. Pulling a read-only view of cloud and SaaS spend by region and service for late March is a cheap, independent check that does not depend on whether your CI retention held.

If any of the five steps returns a positive or an unknown, the response is credential rotation, and rotating the LiteLLM master key alone does not cover it. The stealer took the environment, not the config: cloud access keys, SSH keys, Kubernetes service account tokens, database passwords, and every model provider key readable from those hosts.

Is the LiteLLM proxy itself secure?

Separately from the supply chain incident, ten advisories were published against the LiteLLM proxy through the first half of 2026. Two were critical: CVE-2026-49468, a CVSS 9.5 authentication bypass where the auth layer derived the route from request.url.path (which Starlette rebuilds from the Host header), so a crafted Host could make the auth gate evaluate a different route than the one FastAPI dispatched; and a SQL injection in proxy API key verification. CVE-2026-59822, rated CVSS 8.8, let a fabricated Bearer token establish an authenticated MCP session because the handler fell back to an empty auth object when validation failed. All three are fixed in 1.84.0.

Earlier in the year, CVE-2026-35029 exposed a missing role check on /config/update, which per the disclosure meant "any authenticated user could modify the proxy's runtime configuration, which could lead to arbitrary file read, admin account takeover, or remote code execution." A separate advisory found passwords stored as unsalted SHA-256 hashes, returned to authenticated users by API, and accepted as login credentials in hash form. Both are closed in 1.83.0.

That list looks worse than it is, and it is worth being fair about why. This is the shape of a project that grew a feature surface first and an auth layer second, then had someone competent look at it properly. Route derivation trusted a header. An admin endpoint forgot a role check. A password path skipped a salt. These are the findings of a first real audit, not evidence of ongoing negligence, and LiteLLM's handling has been better than most: specific public advisories with real technical detail, honest scoping (they stated plainly that "most deployments are not affected" by the Host header bypass because upstream proxies and WAFs block it), an external audit after the March incident, and a bug bounty.

The practical read: the proxy is now roughly as trustworthy as any comparably young piece of infrastructure that sits in a privileged position. That is not damning. It is just an argument for treating it as infrastructure, which means someone owns upgrading it.

Does LiteLLM protect against prompt injection?

Partly, and better than most teams realize. The proxy supports guardrails from Presidio, Lakera, Aporia, Bedrock, Guardrails AI, Azure Content Safety, Cato Networks and OpenAI Moderation, plus a native content filter and secret hiding, running at pre_call, during_call and post_call hooks. If your requirement is scanning prompts and completions for PII, secrets and obvious injection attempts, that covers it, and note that model-level guardrails and per-key controls are Enterprise features rather than open source ones.

The limit is structural rather than a gap in the implementation. A guardrail on a model proxy inspects text going to and coming from a model. It does not see what the agent does with the answer. When a coding agent decides to run a shell command, when a support agent decides to issue a refund, when a research agent decides to POST to an internal endpoint, none of that is a model call and none of it passes through LiteLLM. We drew the same boundary in AI gateway vs API gateway, and it is why AI gateway security and tool permissions are separate concerns on this site.

So: if LiteLLM fronts chat completions that return text to a human, it is sufficient on its own and you do not need another layer. If an agent takes the output and acts, the authorization decision has to happen where the action happens.

The part worth remembering after the CVEs are patched

Every organization in that 2,500 had a threat model. Almost none of them had one that included "our LLM proxy library steals our AWS keys during a routine build." The reason is that AI infrastructure got adopted the way good developer tools always do, from the bottom up, and it landed in an unusually privileged spot: a component that every model call flows through, holding every provider key, on a host that also carries cloud credentials, installed by CI without a hash pin.

That concentration is the actual finding, and it generalizes past LiteLLM. The same reasoning applies to the frameworks in LangChain security, to the automation platforms in n8n security, and to any MCP server your agents connect to. Three questions cover most of it: what could this component read if it were hostile, who is accountable for its version, and what would still be true after it was compromised?

The third question is the one that changes architecture. If the answer is "nothing, it saw everything and its logs are on the same host," that is the thing to fix, and it is fixable independently of any vendor's patch cadence. Give each agent a scoped identity rather than a shared key, gate irreversible actions on the action itself rather than on the prompt, and keep the record of what was requested, allowed and denied somewhere the compromised host cannot edit. The full version-by-version breakdown, the advisory table and the hardening checklist are on our LiteLLM security page.