LiteLLM Security: Proxy Vulnerabilities, CVEs, the PyPI Supply Chain Attack and How to Secure LiteLLM
For about 40 minutes on March 24, 2026, the most widely deployed open source LLM proxy shipped an information stealer to PyPI. Roughly 2,500 organizations installed it.
Direct answer
LiteLLM security has two separate stories and teams keep conflating them. The first is the March 2026 supply chain compromise: versions 1.82.7 and 1.82.8 were published to PyPI carrying credential-stealing code, they were live for about 40 minutes before PyPI quarantined them, and the payload harvested environment variables, SSH keys, AWS, GCP and Azure credentials, Kubernetes tokens and database passwords, then installed persistence that ran on every Python invocation in that environment. If either version ever touched your infrastructure, upgrading does not fix it, because the secrets already left. The second story is the ordinary one: ten security advisories published against the LiteLLM proxy between April and June 2026, two of them critical, including a CVSS 9.5 authentication bypass via Host header injection and a SQL injection in proxy API key verification. Those are all patched, and 1.84.0 or later closes the published set. Neither story touches the third problem, which is that a gateway authenticating and routing model calls does not see which tools an agent then invokes on the other side. This page separates the three, cites the GitHub Advisory Database, NVD and LiteLLM's own incident write-ups rather than summaries, and includes a table where several rows say plainly that we are not the fix.
Try it live
Watch Agentshield block an attack in real time.
Pick a scenario and drive the inspection lane yourself. No signup needed.
Run a request
Inspection lane
INSPECTINGPolicy trace
High-risk action held for approval
Audit trail
- § · → → →
The risk
LiteLLM got adopted the way good infrastructure usually does: one team put it in front of OpenAI to control spend, then another pointed Claude Code at it, then it quietly became the single path every model call in the company takes. It now holds provider keys for every vendor you use, issues virtual keys to teams who treat them as permanent, and sits on a host with cloud credentials in its environment. Nobody owns upgrading it. When the PyPI incident broke in March, most teams could not answer the only question that mattered, which was whether 1.82.7 or 1.82.8 had ever been resolved by any build, container image or CI job anywhere in the estate.
How Agentshield handles it
Split the work into three buckets, because they need different owners. Patching handles the advisory backlog and the floor is concrete: 1.84.0 or later closes the two criticals and the MCP authentication bypass, and everything below 1.83.0 carries the earlier privilege escalation and password hash exposure issues. Incident response handles the supply chain compromise, and it is credential rotation, not upgrading: search for litellm_init.pth, check whether 1.82.7 or 1.82.8 appears in any lockfile or image history, and rotate every secret that was readable from those environments. The third bucket is the one no version number reaches. LiteLLM authenticates the caller and routes the model call, which is genuinely useful, and it can run guardrails at pre_call, during_call and post_call hooks. What it does not do is govern what happens after the model answers, when an agent decides to call a tool, hit an internal API or write to a system of record. Enforcement for that has to sit on the action path, with a scoped identity per agent, a human gate on irreversible operations, and an append-only record kept off the proxy host.
The controls
The controls that secure the LiteLLM proxy your teams route model traffic through, and the agents that call tools on the other side of it.
The LiteLLM supply chain attack: what happened in March 2026
This is the incident that matters most, because it is the only one where patching does not help you.
On March 24, 2026, two malicious LiteLLM releases appeared on PyPI. LiteLLM states in its own incident write-up that "the compromised PyPI packages were litellm==1.82.7 and litellm==1.82.8" and that those packages "were live on March 24, 2026 from 10:39 UTC for about 40 minutes before being quarantined by PyPI." Forty minutes sounds survivable. It was not, because PyPI is pulled by machines, not people. LiteLLM was seeing roughly 3.4 million downloads a day at the time, and SecurityWeek reported that over 2,500 organizations were affected.
The payload was a credential stealer. According to LiteLLM, the compromised versions harvested environment variables, SSH keys, cloud provider credentials for AWS, GCP and Azure, Kubernetes tokens and database passwords, and exfiltrated them by POST to models.litellm.cloud, which LiteLLM notes is not an official BerriAI or LiteLLM domain. Datadog Security Labs, which tracked the wider campaign, found that 1.82.8 shipped a .pth file that "executes automatically when the Python interpreter starts," making it materially worse than 1.82.7, which required the proxy module to be imported. Datadog also documented AES-256 and RSA-4096 encryption of the stolen data, persistence installed at ~/.config/sysmon/sysmon.py with a systemd unit, and the implant polling an attacker domain for follow-on instructions.
The origin is worth sitting with. LiteLLM states it 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 security scanner was the entry point into a security-adjacent project's release pipeline. The same campaign also hit Telnyx on PyPI three days later.
| Question | Answer |
|---|---|
| Which versions were malicious? | 1.82.7 and 1.82.8 only. 1.82.8 is the higher-risk of the two because it executed on any Python start, not just on import |
| Does upgrading fix it? | No. Upgrading removes the code. It does not un-steal the credentials it already sent |
| What do I actually check? | Look for litellm_init.pth on disk, and search lockfiles, container image history and CI logs for either version |
| What do I actually do? | Rotate every secret readable from those environments: cloud keys, SSH keys, Kubernetes tokens, database passwords, provider API keys |
| Am I safe if I pin versions? | Pinning helped only if your pin predates 1.82.7. Floating ranges and unpinned CI builds are where this landed |
If you cannot answer row three with evidence rather than memory, treat the answer as yes and rotate. That is the cheaper mistake.
LiteLLM vulnerabilities: the 2026 CVE and advisory record
Separate from the supply chain incident, the LiteLLM proxy accumulated a substantial advisory backlog through the first half of 2026. All of the following are published in the GitHub Advisory Database, and all are fixed.
| Advisory | Severity | What it did | Fixed in |
|---|---|---|---|
| CVE-2026-49468, Host header injection | Critical, CVSS 9.5 | 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, reaching protected management routes unauthenticated | 1.84.0 |
| SQL injection in proxy API key verification | Critical | Injection reachable through the key verification path | See advisory GHSA-r75f-5x8p-qvmc |
| CVE-2026-59822, MCP authentication bypass | High, CVSS 8.8 | The MCP auth handler fell back to an empty UserAPIKeyAuth() object when Bearer token validation failed, letting a fabricated Authorization header establish an authenticated MCP session and invoke configured MCP tools | 1.84.0 |
| CVE-2026-35029, privilege escalation | High | The /config/update endpoint lacked role verification. Per the disclosure, "any authenticated user could modify the proxy's runtime configuration, which could lead to arbitrary file read, admin account takeover, or remote code execution" | 1.83.0 |
| CVE-2026-35030, OIDC cache collision | Critical | Authentication bypass, but only where enable_jwt_auth was explicitly enabled. LiteLLM states "the default LiteLLM configuration is not affected" | 1.83.0 |
| Password hash exposure, GHSA-69x8-hrgq-fjj8 | High | Passwords stored as unsalted SHA-256, endpoints returned the hashes to authenticated users, and login accepted a raw hash as the credential, which is pass-the-hash | 1.83.0 |
Three more landed on June 30, 2026: an MCP OAuth2 passthrough issue, arbitrary file write via path traversal in Skills archive extraction, and a sandbox escape in the custom-code guardrail. That last one deserves a note, because a guardrail that can be escaped is worse than no guardrail if you sized your risk around it.
Two things are worth saying in LiteLLM's favor, because a vendor page that only lists the bad parts is not useful. First, the disclosures are public, specific and timely, which is more than several commercial products in this market manage. Second, LiteLLM scoped the impact honestly rather than minimizing it: on the Host header bypass it stated plainly that "most deployments are not affected" and that upstream components which validate or normalize the Host header, such as a CDN, WAF or reverse proxy with server name allowlists, block it. That is a real mitigating detail and it happens to be true of most production deployments. After the March incident LiteLLM also brought in an external audit and launched a bug bounty.
The practical version floor: run 1.84.0 or later. That closes both criticals and the MCP bypass. Verify the version the process is actually running rather than the one in your manifest, which is the same discipline that catches drift in MCP server security reviews.
Is LiteLLM safe to use in production?
Yes, on a current version, with the credential blast radius reduced and someone accountable for upgrading it. That is a real answer rather than a hedge, and here is the reasoning behind each part.
The platform risk is now ordinary. Ten advisories in a quarter looks alarming until you compare it with any other rapidly growing open source project that suddenly acquired an auth layer, an admin UI, a database and an MCP surface. The pattern in the LiteLLM advisories is consistent and it is the pattern of a project whose security model was added after its feature surface: route derivation trusted a header, an admin endpoint forgot a role check, a password path used an unsalted hash. Those are the flaws you find when someone finally looks, and someone finally looked.
The concentration risk is the durable one. A proxy that every model call passes through is, by design, the place where every provider key lives. LiteLLM's virtual key system is the right answer to that: teams get scoped, revocable, budgeted keys instead of the raw provider credential. Most deployments we see undermine it in the same two ways, by minting virtual keys that never expire and by leaving the master key in a shared environment file on a host that also carries cloud credentials. The March incident is the argument for fixing both, because what made it expensive was not the proxy, it was everything else readable from the proxy's environment.
The residual risk is architectural and no version fixes it. LiteLLM sits between your application and the model. Agents act after the model responds. We cover that split in the next section.
Does LiteLLM have guardrails, and where do they stop?
It does, and they are better than most teams realize. LiteLLM's proxy supports guardrails from Aporia, Lakera, Presidio, Bedrock, Guardrails AI, Azure Content Safety, Cato Networks and OpenAI Moderation, plus a native content filter, secret hiding, and a generic guardrail API for anything else. They run on four hooks: pre_call before the model executes, during_call in parallel with the model call, post_call on input and output afterwards, and logging_only, which masks sensitive data in logs without blocking the request.
If your requirement is "scan prompts and completions for PII, secrets and obvious injection attempts," LiteLLM plus one of those providers genuinely covers it and you do not need us for that. Two caveats worth knowing before you plan around it. Model-level guardrails, tag-based modes and per-key guardrail controls are Enterprise features, not open source ones, so check which side of that line your design sits on. And the June 2026 sandbox escape in the custom-code guardrail is a reminder that a guardrail is code with the same failure modes as other code.
The boundary is structural rather than a gap in the implementation. A guardrail on a proxy inspects text going to and coming from a model. It does not see, and cannot authorize, what the agent does next. 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 the proxy. That is the same reason we distinguish a model gateway from an agent control point in AI gateway vs API gateway, and it is why AI gateway and tool permissions are separate pages on this site rather than one.
How to secure LiteLLM: the hardening checklist
Ordered by how much risk each step removes per hour spent, not by how interesting it is.
- Establish whether you were in the March blast radius. Search every lockfile, image layer and CI log for 1.82.7 and 1.82.8, and look for
litellm_init.pthon any host that ran a pip install in that window. Do this before anything else on this list. - Rotate if the answer is yes or unknown. Cloud keys, SSH keys, Kubernetes service account tokens, database passwords, and every model provider key the environment could read. Rotating the LiteLLM master key alone is not sufficient, because the stealer took the environment, not the config.
- Upgrade to 1.84.0 or later and verify the running version by querying the process, not by reading a manifest.
- Put a reverse proxy or WAF in front that normalizes and allowlists the Host header. This blocks CVE-2026-49468 independently of the version, and it is defense you keep for the next routing flaw.
- Do not expose the admin UI or management routes to the internet. Several of the 2026 advisories are only interesting to an attacker who can reach
/config/updateand similar endpoints. - Give every team and every agent its own virtual key with a budget, a rate limit and an expiry. A key with no expiry is a credential you have decided never to rotate.
- Get the master key out of shared environment files and into a secrets manager with short-lived retrieval, and stop running the proxy on a host that carries broad cloud credentials.
- Review the MCP servers the proxy exposes. After CVE-2026-59822, assume MCP surface is auth surface. Allowlist servers, pin tool definitions, and log every call.
- Turn on guardrails for PII and secret detection at
pre_callandpost_call, and confirm which of the controls you are relying on are Enterprise-gated. - Ship the logs somewhere LiteLLM cannot rewrite. If the proxy host is compromised, its own logs are the first thing an attacker edits. See audit trail.
Steps one and two are the ones teams skip because they are unglamorous and produce no diff. They are also the only steps on this list that address damage that has already happened.
What a runtime control point does and does not fix for LiteLLM
We sell an agent policy layer, so read this table skeptically. It is written to be accurate rather than flattering, and the first three rows are a flat no.
| LiteLLM risk | Does an agent control point help? | What actually fixes it |
|---|---|---|
| A malicious LiteLLM package stealing credentials from the host environment | No. That is code executing on your infrastructure at install time, before any request reaches any policy layer | Dependency pinning with hash verification, isolated build environments, and rotating what leaked. Nothing at the request layer touches this |
| An authentication bypass in the proxy, like the Host header flaw | No. That is a flaw inside the component itself | Upgrading to 1.84.0 or later, plus Host header normalization upstream. Two independent controls, not one |
| Scanning prompts and completions for PII, secrets and injection attempts | No, and you do not need us for it. LiteLLM already runs Presidio, Lakera, Bedrock and others on its own hooks | LiteLLM guardrails at pre_call and post_call. Use the thing you already have |
| Prompt injection arriving through a document, ticket or scraped page an agent reads | Partly. We inspect untrusted content before an agent acts on it, and no filter is complete. We will not claim otherwise | Containment over detection: assume it lands, then constrain what the agent can do next. See prompt injection protection |
| An agent calling a tool, an internal API or a production system after the model responds | Yes. This never passes through the model proxy, and it is the actual enforcement point | Per-agent scoped identity and a default-deny tool policy applied where the call is made. See tool permissions |
| An irreversible action, such as a payment, a deletion or an outbound email | Yes. Held for human approval based on the action, not the prompt | An approval gate on the action path. See human in the loop AI agents |
| No trustworthy record of what an agent did during an incident | Yes. An append-only log of requested, allowed and denied calls, held off the proxy host | An audit trail the compromised host cannot edit, which is the only artifact that survives that host |
Three flat no, one partly, three yes. If you are running a vendor evaluation, ask every vendor in this market for the same table and treat an all-green response as a reason to look harder rather than a reason to shortlist. Our survey of who genuinely does what is in AI agent security companies.
The honest summary of LiteLLM security is that LiteLLM had a bad first half of 2026 and handled it better than most projects would have: public advisories with real technical detail, honest scoping of what was and was not affected, an external audit and a bug bounty afterwards. The version floor closes the published set. What remains is not a LiteLLM problem at all. It is that routing every model call through one place solves authentication, cost control and provider abstraction, and solves nothing about what an agent does once the model has answered. That is the same boundary described in LangChain security and coding agent security, and it is where enforcement has to move.
FAQ
Common questions about litellm security.
Is LiteLLM safe?
On 1.84.0 or later, yes, with normal infrastructure hygiene. That version closes both critical 2026 advisories and the MCP authentication bypass. The caveat is historical rather than current: if versions 1.82.7 or 1.82.8 ever ran anywhere in your estate during the March 2026 supply chain incident, upgrading does not help, because the credentials in that environment were already exfiltrated.
Is LiteLLM safe now?
The malicious packages were quarantined by PyPI within about 40 minutes on March 24, 2026 and are no longer installable, and LiteLLM subsequently commissioned an external audit and launched a bug bounty. Current releases are clean. Safety now depends on your version and your exposure, not on whether the package index is compromised today.
What happened in the LiteLLM supply chain attack?
On March 24, 2026, litellm 1.82.7 and 1.82.8 were published to PyPI containing credential-stealing code. They were live about 40 minutes before quarantine. The payload harvested environment variables, SSH keys, AWS, GCP and Azure credentials, Kubernetes tokens and database passwords, and installed persistence. SecurityWeek reported over 2,500 organizations affected.
What version of LiteLLM is safe?
Run 1.84.0 or later. That floor closes CVE-2026-49468, the CVSS 9.5 Host header authentication bypass, the critical SQL injection in proxy API key verification, and CVE-2026-59822, the CVSS 8.8 MCP authentication bypass. Versions below 1.83.0 additionally carry the privilege escalation on /config/update and the unsalted password hash exposure.
What is CVE-2026-49468?
A critical authentication bypass in the LiteLLM proxy, CVSS 9.5. The auth layer derived the effective route from request.url.path, which Starlette reconstructs from the Host header, so a crafted Host could make the auth gate evaluate a different route than the one FastAPI dispatched, reaching protected management routes unauthenticated. Fixed in 1.84.0.
How do I secure LiteLLM?
Confirm whether 1.82.7 or 1.82.8 ever ran in your estate and rotate secrets if so, upgrade to 1.84.0 or later, put a reverse proxy or WAF in front that normalizes the Host header, keep management routes off the internet, issue expiring per-team virtual keys, move the master key into a secrets manager, and ship logs somewhere the proxy host cannot edit.
Is the LiteLLM proxy secure enough for enterprise use?
For authentication, routing, spend control and provider abstraction, yes on a current version, and its virtual key model is genuinely good. What it does not provide is authorization over agent actions. If your agents call tools, internal APIs or systems of record, that traffic never passes through the model proxy and needs a separate enforcement point.
Does LiteLLM have guardrails?
Yes. The proxy supports Aporia, Lakera, Presidio, Bedrock, Guardrails AI, Azure Content Safety, Cato Networks and OpenAI Moderation, plus a native content filter and secret hiding, running on pre_call, during_call, post_call and logging_only hooks. Note that model-level guardrails, tag-based modes and per-key controls are Enterprise features rather than open source ones.
Do I still need an agent security layer if I run LiteLLM?
Only if your agents act. If LiteLLM fronts chat completions that return text to a human, it is sufficient on its own. If an agent takes the model output and calls a tool, runs a command or writes to a production system, that path bypasses the proxy entirely, so authorization and audit for it have to be enforced where the action happens.
Was LiteLLM Cloud affected by the 2026 vulnerabilities?
LiteLLM states that LiteLLM Cloud customers were not affected by the Host header authentication bypass, and that no LiteLLM Cloud customers had the enable_jwt_auth feature enabled that the OIDC cache collision required. Verify current status with the vendor rather than relying on this page, since hosted deployments change.
Does Agentshield replace LiteLLM?
No, and it is not meant to. LiteLLM handles model routing, provider keys, spend control and prompt-level guardrails, and it does those well. We sit on the other side, governing which tools an agent may invoke, gating irreversible actions for human approval, and keeping an append-only record off the proxy host. Teams commonly run both.
More use cases