A default low-privilege account on a LiteLLM proxy can climb to full admin and run code on the server by chaining three vulnerabilities, researchers at Obsidian Security disclosed
LiteLLM is a widely deployed open-source AI gateway that brokers calls to more than 100 model providers behind one OpenAI-compatible interface.
A server takeover exposes every provider key it holds, the secrets that decrypt its stored credentials, and every prompt and response passing through it.
Obsidian rates the full chain CVSS 9.9, in the Critical range. BerriAI, the maintainer, included the complete fix set in LiteLLM v1.83.14-stable, which GitHub lists as released May 2. Upgrade to that release or later to close the three-CVE chain.
The three bugs
The first link is CVE-2026-47101, an authorization bypass. When a regular user (an internal_user) generates a virtual API key, LiteLLM stores the caller-supplied allowed_routes field without checking it against the user’s role.
The field is supposed to narrow what a key can do. Instead, the proxy also treats it as a fallback grant, so a non-admin can mint a key with allowed_routes: [“/*”], a wildcard that reaches every route, including admin-only ones. The same unchecked write shows up on the other key-management endpoints, which is why the fix took three pull requests to land.
With the route gate bypassed, the handlers behind it become reachable. Several of them assume the gate has already done the screening, which opens two paths.
One is CVE-2026-47102, privilege escalation. The /user/update endpoint lets a user edit their own record, but does not restrict which fields they can write. A self-update with user_role: “proxy_admin” is accepted and saved, promoting the caller to full proxy admin. An org_admin can hit this endpoint through a legitimate, intended code path with no bypass required; a default internal_user reaches it after CVE-2026-47101.
VulnCheck, which assigned the CVE, scores it 8.7 under CVSS 4.0, 8.8 under 3.1.
The other is CVE-2026-40217, a sandbox escape in the Custom Code Guardrail, which compiles and runs admin-supplied Python. The production endpoints ran the code through exec() with no source-level filtering. When exec() gets a globals dict without __builtins__, Python silently injects the full builtins module, which hands the code __import__, open, and eval. A plain payload calling os.system was then enough for a reverse shell.
A separate path on the /guardrails/test_custom_code playground endpoint, found independently by X41 D-Sec, defeated a regex deny-list through runtime bytecode rewriting. Both ended in server-side code execution.
What an attacker gets
LiteLLM sits at a chokepoint, so the reach is wide. A full chain 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 the rest.
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, which in real deployments is where PII, source code, internal tickets, and pasted secrets end up.
If the proxy also runs as a Model Context Protocol (MCP) or agent gateway, OAuth tokens and tool credentials are in scope too.
The sharper risk is not what an attacker reads but what they can rewrite. The gateway sits on the wire between an AI agent and the model, so a compromise lets it alter responses in transit.
Obsidian demonstrated this against Claude Code routed through a compromised proxy. This is not prompt injection. Instead of persuading the model to misbehave, the attacker uses LiteLLM’s built-in callback mechanism, an extension point that fires on every request and never shows up in the admin UI. The callback swaps the model’s response for a forged tool call and rewrites 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.
Separate from the chain, LiteLLM hands a proxy_admin an intentional code-execution path: its MCP support lets an admin register stdio MCP servers that the proxy launches as local subprocesses. That is a design trade-off rather than a bug, and the patches do not change it, so reaching admin is effectively reaching code execution.
Obsidian reproduced a reverse shell this way on v1.88.0. A genuine bug in the same stdio-MCP machinery, CVE-2026-42271, let callers spawn subprocesses through LiteLLM’s MCP preview endpoints; it was exploited in the wild and added to CISA’s KEV catalog earlier this month.
None of this is 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.
Obsidian frames the chain here as a disclosed flaw with a working demo, not as exploitation seen in the wild, but the proxy’s position keeps making it a target.
What to do
Upgrade to v1.83.14-stable or later, the first release with the full fix set. Then audit. Re-verify every account holding proxy_admin and treat that role as host-level access. Review every Custom Code Guardrail on the proxy.
Check the 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. Verify the integrity of the deployed code, not just the config. If exposure is suspected, rotate provider keys, database credentials, and any stored MCP tokens.
A compromised proxy does not just leak data. It sits between the agent and the model and can forge the responses that the agent acts on. 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.
