LiteLLM Vulnerability Chain Lets Low-Privilege Users Take Over AI Gateway Servers
A chain of three vulnerabilities in the open-source AI gateway LiteLLM allows low-privilege users to escalate to full admin and achieve remote code execution, exposing provider API keys and secrets.
Obsidian Security has disclosed a critical vulnerability chain in LiteLLM, the widely used open-source AI gateway that brokers calls to over 100 model providers. The chain, rated CVSS 9.9, allows a default low-privilege user to escalate to full proxy admin and execute arbitrary code on the server, exposing every provider API key, decryption secrets, and all prompts and responses passing through the gateway.
The first link in the chain is CVE-2026-47101, an authorization bypass. When a regular user generates a virtual API key, LiteLLM stores the caller-supplied allowed_routes field without validating it against the user's role. This allows a non-admin to mint a key with a wildcard route that reaches admin-only endpoints. With the route gate bypassed, two additional vulnerabilities become exploitable.
CVE-2026-47102 is a privilege escalation flaw in the /user/update endpoint, which lets a user edit their own record without restricting which fields they can write. A self-update with user_role: "proxy_admin" is accepted and saved, promoting the caller to full proxy admin. VulnCheck assigned this CVE a CVSS score of 8.7 under CVSS 4.0. The third bug, CVE-2026-40217, is a sandbox escape in the Custom Code Guardrail, which compiles and runs admin-supplied Python via exec() with no source-level filtering, allowing a reverse shell with a simple os.system payload.
A full chain compromise exposes the master key, the salt key that decrypts stored credentials, and the database URL. It also exposes every configured provider key for OpenAI, Anthropic, Gemini, Bedrock, Azure, and others. Keys in config or environment are plaintext; keys in the database are encrypted but recoverable with the salt key. Everything sent through the gateway—prompts and responses—becomes readable, including PII, source code, internal tickets, and pasted secrets. If the proxy also runs as a Model Context Protocol (MCP) or agent gateway, OAuth tokens and tool credentials are in scope.
The sharper risk is not just data theft but response manipulation. The gateway sits between an AI agent and the model, so a compromise lets an attacker alter responses in transit. Obsidian demonstrated this against Claude Code routed through a compromised proxy, using LiteLLM's built-in callback mechanism to swap the model's response for a forged tool call and rewrite the safety-check context so the action reads as approved. In the demo, the developer types one word, "hello," and the attacker pops a reverse shell on the developer's machine.
BerriAI, the maintainer, included the complete fix set in LiteLLM v1.83.14-stable, released May 2. Users are urged to upgrade immediately and then audit every account holding proxy_admin, review every Custom Code Guardrail, and check callbacks loaded from config.yaml under litellm_settings.callbacks, since those never appear in the console and are exactly where a post-RCE attacker would hide. If exposure is suspected, rotate provider keys, database credentials, and any stored MCP tokens.
This is not LiteLLM's first rough stretch this year. In March, a supply-chain compromise backdoored two LiteLLM releases on PyPI, and in April, a critical SQL injection was exploited within 36 hours of disclosure. The proxy's position as a chokepoint between AI agents and models continues to make it a high-value target. As Obsidian notes, the chain that gets an attacker there is misplaced trust at every layer: the route gate trusted the caller-supplied field, the handlers trusted the route gate, and nobody actually checked.