# LiteLLM's Rough 2026: 3 CISA KEV Flaws, a 9.9 CVE, and a Poisoned PyPI Release

URL: https://www.devopsness.com/blog/litellm-vulnerabilities-2026
Author: Kiril Urbonas
Published: 2026-10-23
Updated: 2026-10-23
Categories: AI
Tags: Security, LLM, Supply Chain, Litellm, AI Security

Summary: Your AI gateway holds every provider key you own. In 2026 LiteLLM shipped 17 security advisories, three of them exploited in the wild. Here is what to patch and how to fence it in.

---
# LiteLLM's Rough 2026: 3 CISA KEV Flaws, a 9.9 CVE, and a Poisoned PyPI Release

If you self-host the LiteLLM proxy, upgrade to 1.104.0 or later (1.106.2 is current as of October 23, 2026), expose only the inference routes, and rotate your provider keys if you ran an affected version on the internet. LiteLLM has published 17 security advisories since March. CISA lists three as actively exploited.

An AI gateway is a credential vault with an HTTP API. It stores your OpenAI, Anthropic, Bedrock, and Vertex keys, mints virtual keys for every team, and increasingly spawns MCP tool servers on its own host. That makes it the most valuable box in most AI stacks, and in 2026 attackers noticed. None of this means LiteLLM is a bad choice; we still recommend it in our [AI gateway comparison](/blog/ai-gateway-comparison). It means you have to run it like the vault it is.

## The newest one: CVE-2026-114612, CVSS 9.9

Discovered by OPSWAT's Unit 515, this lets any user with `internal_user` rights escalate to `proxy_admin` and then execute commands on the host. The root cause is one encryption key doing two jobs: sealing secrets at rest and minting session tokens. An attacker asks the proxy to create an API key whose metadata carries a forged admin credential as the "secret." The proxy encrypts it and hands it back. Present that ciphertext as a bearer token, and the proxy decrypts it and trusts the admin identity inside. From there, the MCP stdio endpoint runs arbitrary commands.

Versions from 1.91.0 are exploitable in the default configuration. Versions 1.87.0 to 1.90.x are exploitable only with `EXPERIMENTAL_UI_LOGIN=true`. Fixed releases are 1.100.4, 1.101.3, 1.102.2, 1.103.1, and 1.104.0rc2 onward. If you can't upgrade today, set `EXPERIMENTAL_UI_LOGIN=false`, which closes the path but breaks CLI SSO and Claude Code gateway login.

## The pattern behind 2026's advisories

Line the high-severity advisories up and the pattern is clear: auth checks that trust the wrong thing, and admin features reachable by non-admins.

| CVE | Bug | Auth needed | CISA KEV | Fixed in |
|---|---|---|---|---|
| CVE-2026-42208 | SQL injection in API key verification | None | Yes, May 8 | 1.83.7 |
| CVE-2026-42271 | Command execution via MCP stdio test endpoints | Any API key | Yes, June 8 | 1.83.7 |
| CVE-2026-59822 | MCP auth bypass via OAuth2 passthrough fallback | None | Yes, Sept 2 | 1.84.0 |
| CVE-2026-49468 | Auth bypass via Host header | None | No | 1.84.0 |
| CVE-2026-35029 | `/config/update` missing admin check, leads to RCE | Any user | No | 1.83.0 |
| CVE-2026-35030 | OIDC cache key collision (JWT auth only) | None | No | 1.83.0 |
| CVE-2026-114612 | Salt key reuse, internal user to proxy admin | Internal user | No | 1.100.4+ |

The SQL injection is the one to fear most. A crafted `Authorization` header on any LLM route, including `POST /chat/completions`, reached a query that concatenated the key into SQL. No account needed, and Sysdig saw the first targeted exploitation attempt 36 hours after the advisory reached the GitHub Advisory Database. The MCP test endpoints (`/mcp-rest/test/connection`, `/mcp-rest/test/tools/list`) spawned whatever `command` you sent as a subprocess, gated only by a valid key with no role check. A one-line upgrade to 1.104.0 or later clears every row in this table.

## The March PyPI compromise is a separate problem

On March 24, attackers who had stolen the maintainer's PyPI credentials, traced back to the compromised Trivy scanner in CI, published `litellm` 1.82.7 and 1.82.8 directly to PyPI. GitHub never saw that code. Version 1.82.7 hid the payload in `proxy_server.py`. Version 1.82.8 added `litellm_init.pth`, and `.pth` files execute on **every Python startup**, no `import` needed. The payload collected SSH keys, cloud and Kubernetes credentials, `.env` files, and shell history, encrypted them, and posted them to `models.litellm.cloud`, a lookalike domain registered the day before.

The official proxy Docker image was not affected because it pins dependencies. Anyone who ran `pip install -U litellm` that afternoon, on a laptop or in CI, should assume every credential on that machine leaked. This is the same playbook we covered in [software supply chain attacks](/blog/software-supply-chain-attacks): steal a publish token, ship straight to the registry, harvest CI secrets.

## Check what you're running

```bash
# Installed version (venv, container, or CI image)
$ pip show litellm | grep -i '^version'
$ kubectl get pods -A -o jsonpath='{range .items[*]}{.spec.containers[*].image}{"\n"}{end}' | grep -i litellm

# Leftovers from the March PyPI compromise
$ find / -name 'litellm_init.pth' 2>/dev/null
$ python -c 'import site; print("\n".join(site.getsitepackages()))' | xargs -I{} sh -c 'ls {}/*.pth 2>/dev/null'

# Any contact with the exfiltration domain in DNS or proxy logs
$ grep -r 'litellm.cloud' /var/log/ 2>/dev/null | head

# Pin exact versions with hashes so a poisoned release can't slip in
$ echo 'litellm[proxy]==1.106.2' > requirements.in
$ uv pip compile --generate-hashes requirements.in -o requirements.txt
$ pip install --require-hashes -r requirements.txt
```

If you find `litellm_init.pth` or any hit for `litellm.cloud`, treat the host as compromised: rotate everything it could read, not just the LiteLLM keys.

## Fence it in so the next CVE is boring

Most of 2026's critical bugs needed an attacker to reach a management or MCP route. Your applications only need a handful of inference paths. Put a reverse proxy in front that validates `Host` and allowlists those paths:

```nginx
# /etc/nginx/conf.d/litellm.conf
server {
    listen 443 ssl;
    server_name llm.internal.example.com;   # rejects forged Host headers
    location ~ ^/(v1/)?(chat/completions|completions|embeddings|models)$ {
        proxy_pass http://litellm:4000;
    }
    location / { return 403; }              # /ui, /config, /mcp-rest, /key stay internal
}
```

That blocks the Host header bypass, the MCP test endpoints, and `/config/update` from outside. It does not stop the SQL injection, which rode on `/chat/completions`, so it complements patching rather than replacing it. Serve the admin UI on a separate internal listener or behind your VPN.

Then reduce what a compromise yields. Give the proxy pod a network policy that allows egress only to your LLM providers and its database. Don't enable MCP stdio servers unless you need them, since stdio means "run a command on this host." Hand out virtual keys with budgets and model allowlists instead of the master key. The same least-privilege thinking applies to agents; see our notes on [AI agent security](/blog/ai-agent-security).

## Questions people ask

### Is LiteLLM safe to use in production?

Yes, if you run it like a credential vault. Stay within a few releases of current, expose only inference routes publicly, keep the admin UI and MCP endpoints internal, and pin installs with hashes. Most 2026 critical CVEs required reaching management routes that a path allowlist would have blocked, though the SQL injection shows patching still comes first.

### Which LiteLLM version fixes CVE-2026-114612?

Versions 1.100.4, 1.101.3, 1.102.2, 1.103.1, and 1.104.0rc2 or later fix it. Versions 1.91.0 and newer were exploitable in the default configuration; 1.87.0 to 1.90.x only with `EXPERIMENTAL_UI_LOGIN=true`. Upgrading to 1.104.0 or later also clears the three CISA KEV flaws.

### Was I affected by the LiteLLM PyPI attack?

Only if you installed 1.82.7 or 1.82.8 from PyPI on March 24, 2026, before they were removed. The official Docker image was not affected. Search for `litellm_init.pth` and check DNS logs for `litellm.cloud`. If either turns up, rotate every credential on that machine, including cloud, Kubernetes, SSH, and CI secrets.

## The decision, concretely

- **Running anything older than 1.84.0?** Upgrade today; three of its bugs are on CISA's exploited list.
- **Proxy reachable from the internet?** Add a Host-validating reverse proxy with a path allowlist this week.
- **Ran a KEV-affected version exposed publicly?** Rotate the master key, virtual keys, and every stored provider key.
- **Installing from PyPI in CI?** Pin with hashes, or use the pinned Docker image.

## The call we'd make

Keep LiteLLM, but stop treating it as a convenience library. Upgrade to current, put it behind a reverse proxy that allows only inference routes, keep MCP stdio off unless a team can justify it, and pin every install. A gateway that holds all your provider keys deserves the patch cadence and network isolation you'd give a secrets manager, because that is what it is.

## Sources

- [LiteLLM advisory GHSA-7hp6-4w63-5g45 (CVE-2026-114612)](https://github.com/BerriAI/litellm/security/advisories/GHSA-7hp6-4w63-5g45)
- [LiteLLM advisory GHSA-r75f-5x8p-qvmc (CVE-2026-42208)](https://github.com/BerriAI/litellm/security/advisories/GHSA-r75f-5x8p-qvmc)
- [CISA Known Exploited Vulnerabilities catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)
- [LiteLLM PyPI compromise timeline (GitHub issue #24518)](https://github.com/BerriAI/litellm/issues/24518)