LiteLLM Security: The CVEs, the Package Poisoning Incident, and How to Stay Safe
LiteLLM is one of the most widely deployed open-source LLM gateways, and that popularity has made its security record a frequent search topic. This breakdown answers what actually happened, with every claim traced to the GitHub Security Advisories and the GitHub Advisory Database. It covers the supply-chain package poisoning incident recorded as GHSA-5mg7-485q-xm76, the 8 official advisories published on the BerriAI/litellm repository, and the 16 documented CVEs spanning 2024 to 2026.
The framing matters as much as the facts. A gateway that brokers credentials for many providers is a high-value target by design, so a long advisory list is partly a function of attention. We separate the two distinct story lines that often get blurred together: a malicious package that was published to a registry, and code vulnerabilities found and fixed in the proxy itself. They are different problems with different fixes.
Why the LiteLLM Proxy Is a High-Value Target
The LiteLLM proxy server sits between your applications and every LLM provider you use. To do its job, it holds the API keys for those providers and exposes a single unified endpoint that your apps call. That is the entire point of an LLM gateway: one place to manage credentials, routing, spend, and policy.
That design also concentrates risk. If an attacker compromises the proxy, the prize is not one key but the whole set of provider credentials it brokers, plus the virtual keys it issues to internal teams. The same property that makes a gateway operationally convenient makes it worth attacking. This is context for why the advisory surface deserves attention, not a claim that any specific deployment has been breached.
Practitioner note: Treat the proxy as a credential vault, not as a stateless utility. The relevant question is not "is LiteLLM secure?" but "is my LiteLLM deployment patched, isolated, and least-privileged?" The answer to the first is a moving target; the answer to the second is under your control.
It is also worth saying plainly: a project having a published advisory list is not the same as a project being unsafe. Visibility cuts both ways. The sections below lay out exactly what has been documented so you can judge the deployment guidance on the evidence.
The Package "Poisoning" Incident
The headline story is a supply-chain compromise, recorded as advisory GHSA-5mg7-485q-xm76 and titled "Two LiteLLM versions published containing credential harvesting malware." It is rated Critical and was published on March 25, 2026. The key fact to internalize is what kind of problem this is: two published package versions contained malware designed to harvest credentials. The malicious code shipped inside the published artifacts.
This is a supply-chain package compromise, not a flaw in the gateway's request-handling logic. The distinction is practical. A code vulnerability is fixed by upgrading to a patched version. A poisoned package is addressed by avoiding the malicious versions entirely, verifying what you install, and rotating any secrets that the malicious code could have observed while it ran. The same upgrade reflex that fixes a CVE does not, on its own, undo credential exposure.
Because the proxy is built to hold provider keys, a credential harvester running inside it has direct access to exactly what it wants. If your environment pulled LiteLLM during the period covered by this advisory, the conservative response is to assume the keys that were present could have been read, and to rotate them. We name the exact mitigation steps in the final section.
The 8 Official BerriAI/litellm Advisories
Beyond the supply-chain incident, the BerriAI/litellm repository publishes 8 GitHub Security Advisories for code vulnerabilities in the proxy. These are the cleanest source on LiteLLM's security record because they are maintainer-published with consistent metadata. Three are rated Critical and five are rated High. The table below lists each one exactly as recorded.
| Advisory | Issue | Severity | Published |
|---|---|---|---|
| GHSA-4xpc-pv4p-pm3w | Authentication bypass via Host header injection | Critical | Late May 2026 |
| GHSA-jjhc-v7c2-5hh6 | Authentication bypass via OIDC userinfo cache key collision | Critical | Apr 3, 2026 |
| GHSA-r75f-5x8p-qvmc | SQL injection in proxy API key verification | Critical | Apr 20, 2026 |
| GHSA-v4p8-mg3p-g94g | Authenticated command execution via MCP stdio test endpoints | High | Apr 21, 2026 |
| GHSA-wxxx-gvqv-xp7p | Sandbox escape in custom-code guardrail | High | May 6, 2026 |
| GHSA-xqmj-j6mv-4862 | Server-side template injection in /prompts/test endpoint | High | Apr 20, 2026 |
| GHSA-69x8-hrgq-fjj8 | Password hash exposure and pass-the-hash authentication bypass | High | Apr 3, 2026 |
| GHSA-53mr-6c8q-9789 | Privilege escalation via unrestricted proxy configuration endpoint | High | Apr 3, 2026 |
A pattern is visible in the issue types. Several advisories cluster around authentication and authorization on the proxy's management surface: header-based auth bypass, an OIDC cache collision, a SQL injection in key verification, a privilege-escalation path through a configuration endpoint, and a pass-the-hash bypass. That cluster reinforces the same operational lesson as the poisoning incident: the proxy's admin and key-management endpoints are the part you most need to keep off the open internet.
The Documented CVE History (2024-2026)
The wider GitHub Advisory Database lists CVEs specific to LiteLLM going back to 2024. One note before reading the table: the flattened advisory feed does not cleanly pair every CVE to a corresponding GHSA, so we present the CVE record on its own and do not assert that any CVE is the same item as any advisory above. Where the database names a fixed version, we include it.
2026
| CVE | Issue | Severity | Fixed in / notes |
|---|---|---|---|
| CVE-2026-42271 | SQL injection in proxy API key verification | Critical | Published Apr 25 |
| CVE-2026-35030 | OIDC authentication bypass | Critical | Published Apr 3 |
| CVE-2026-47102 | User can modify own user_role via /user/update | High | Prior to 1.83.10 |
| CVE-2026-47101 | Authenticated internal_user can create API keys | High | Prior to 1.83.14 |
| CVE-2026-40217 | Sandbox escape in custom-code guardrail | High | Not specified |
| CVE-2026-42208 | Server-side template injection in /prompts/test | High | Published Apr 24 |
| CVE-2026-42203 | Sandbox escape (flagged duplicate advisory) | High | Published Apr 24 |
| CVE-2026-35029 | Privilege escalation via proxy config endpoint | High | Published Apr 3 |
2025
| CVE | Issue | Severity | Fixed in / notes |
|---|---|---|---|
| CVE-2025-0628 | Improper authorization | High | Published Mar 20 |
| CVE-2025-0330 | Langfuse API key leakage | High | Published Mar 20 |
| CVE-2025-45809 | SQL injection via /key | Moderate | Affects 1.65.4 · Jul 3 |
| CVE-2025-11203 | API key information disclosure | Low | Published Oct 29 |
2024
| CVE | Issue | Severity | Fixed in / notes |
|---|---|---|---|
| CVE-2024-6825 | Remote code execution | High | Not specified |
| CVE-2024-9606 | API key portion revealed via logging file | High | Not specified |
| CVE-2024-8984 | Denial of service via crafted HTTP request | High | Not specified |
| CVE-2024-10188 | Denial of service | High | Not specified |
One housekeeping detail rounds out the record. A separate advisory for password hash exposure, GHSA-3926-2jvf-fg29, was withdrawn, and CVE-2026-42203 is flagged as a duplicate. Both are signs of advisory hygiene rather than additional distinct issues, so do not double-count them when tallying LiteLLM's exposure.
Responsible Disclosure: Reading the Signal Correctly
A long advisory list invites a snap judgment, but the more useful reading is how the issues are handled. LiteLLM's maintainers publish formal GitHub Security Advisories and ship fixes in versioned releases. The 2026 CVE record names concrete fixed versions for some issues: the user_role modification flaw was addressed prior to 1.83.10, and the API-key creation flaw prior to 1.83.14.
The withdrawal of GHSA-3926-2jvf-fg29 and the duplicate flag on CVE-2026-42203 point in the same direction. A project that withdraws an advisory it deems incorrect and marks duplicates is maintaining its advisory data, not letting it accumulate noise. That is the behavior of an active security process.
None of this erases the supply-chain incident, which sits in a different category from a patched code bug. The honest summary is that LiteLLM has a substantial published vulnerability record and a maintainer team that documents and patches issues openly. Both halves of that sentence are true, and a security decision should weigh both rather than fixate on either one.
How to Stay Safe: A Hygiene Checklist
The guidance below is standard operational hygiene for any credential-holding service, applied to the LiteLLM proxy. None of it is exotic. The reason it matters here is the concentration of value behind one endpoint that the first section described.
Translated into actions, the checklist is: pin to -stable release tags rather than chasing the latest build; upgrade past every fixed version that applies to your deployment; keep the proxy on a private network so its management and configuration endpoints are not internet-facing; scope virtual keys to the minimum each key, team, or user needs; rotate any provider keys that were loaded during the malicious-version window covered by the poisoning advisory; and verify package integrity with hashes or lockfiles before you install.
The last two items are the ones teams skip. Rotation is the only reliable answer to the credential-harvesting incident, because an upgrade cannot un-leak a key that was already read. Integrity verification is what stops a poisoned package from reaching your environment in the first place. Together they address the supply-chain story that a patch cycle alone does not.
Bottom line: LiteLLM is a capable open-source gateway with a visible, actively maintained security record. Run it like the credential vault it is, keep it current and isolated, and rotate keys if you were exposed during the poisoning window. The risk is manageable with discipline; it is not self-managing.
Frequently Asked Questions
Was LiteLLM itself hacked, or was the package poisoned?
These are two different things. Advisory GHSA-5mg7-485q-xm76 (Critical, March 25, 2026) records that two published LiteLLM versions contained credential-harvesting malware. That is a supply-chain package compromise: malicious code shipped inside published artifacts, not a logic flaw in the gateway code. Separately, LiteLLM has a documented history of code vulnerabilities tracked as CVEs and GitHub Security Advisories. The two categories carry different threat models and different fixes.
How many security advisories does LiteLLM have?
The BerriAI/litellm repository publishes 8 official GitHub Security Advisories, of which three are rated Critical and five are rated High. The wider GitHub Advisory Database lists 16 documented CVEs for LiteLLM across 2024, 2025, and 2026. One advisory (GHSA-3926-2jvf-fg29) was withdrawn and one CVE (CVE-2026-42203) is flagged as a duplicate, so neither should be counted as a distinct active issue.
Which LiteLLM versions fix the recent vulnerabilities?
The advisory metadata names some fixed versions: CVE-2026-47102 was addressed prior to 1.83.10, and CVE-2026-47101 prior to 1.83.14. The general guidance is to run the latest -stable release and upgrade past every fixed version that applies to you. The exact malicious version numbers in the poisoning incident were not disclosed in the public advisory, so do not rely on a remembered version string.
Is LiteLLM safe to run in production?
It can be, with standard hygiene. Because the proxy brokers every provider API key behind one endpoint, treat it like any other credential-holding service: pin to -stable releases, upgrade past fixed versions, keep management endpoints off the public internet, scope virtual keys to least privilege, rotate any keys loaded during the malicious-version window, and verify package integrity before install. For context on what a gateway does, see our explainer on what LiteLLM is.
Video Resources
Go Deeper
Resources from across Tech Jacks Solutions
Cybersecurity News Center
CVE coverage, advisories, and threat intelligence
Agent Threat Landscape
Security risks specific to AI agent infrastructure
PREMIUMPre-Deployment Safety Gate
27-point checklist before any AI tool goes live
EU AI Act Overview
Governance context for deploying AI infrastructure