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, placing it firmly 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 in the chain 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 `allowed_routes` field is intended to narrow what a key can do. Instead, the proxy also treats it as a fallback grant, allowing a non-admin to mint a key with `allowed_routes: ["/*"]`, a wildcard that reaches every route, including admin-only ones. The same unchecked write shows up on other key-management endpoints, necessitating three pull requests for a complete fix. With the route gate bypassed, the handlers behind it become reachable. Several of these handlers assume the gate has already performed the necessary screening, which opens two critical paths. One path is **CVE-2026-47102**, a privilege escalation vulnerability. The `/user/update` endpoint allows a user to 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 administrator. An `org_admin` can hit this endpoint through a legitimate, intended code path with no bypass required; a default `internal_user` reaches it after exploiting **CVE-2026-47101**. **VulnCheck**, which assigned the CVE, scores it 8.7 under CVSS 4.0 and 8.8 under 3.1. The other path 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()` receives a `globals` dict without `__builtins__`, Python silently injects the full `builtins` module, providing the code with `__import__`, `open`, and `eval`. A simple payload calling `os.system` was then sufficient 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 methods ultimately resulted in server-side code execution. ## What an Attacker Gets **LiteLLM** sits at a chokepoint, giving the exploit wide reach. 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 others. Keys in configuration or environment variables are plaintext; keys in the database are encrypted but recoverable with the salt key. Everything sent through the gateway, including prompts and responses, becomes readable. In real deployments, this often includes 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 also in scope. The sharper risk is not merely what an attacker reads but what they can rewrite. The gateway sits on the wire between an AI agent and the model, meaning a compromise allows it to alter responses in transit. **Obsidian** demonstrated this against **Claude Code** routed through a compromised proxy. This is not prompt injection. Instead, the attacker uses **LiteLLM**'s built-in callback mechanism, an extension point that fires on every request and never appears 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, a developer types one word, "hello," and the attacker pops a reverse shell on the developer's machine. Separate from this chain, **LiteLLM** provides a `proxy_admin` with an intentional code-execution path: its MCP support allows an admin to register stdio MCP servers that the proxy launches as local subprocesses. This is a design trade-off rather than a bug, and the patches do not change it, making reaching admin access effectively equivalent to achieving 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**, allowed callers to 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 patch this year. In March, a supply-chain compromise backdoored two **LiteLLM** releases on **PyPI**, and in April, a critical SQL injection (**CVE-2026-42208**) was exploited within 36 hours of disclosure. **Obsidian** frames the current chain as a disclosed flaw with a working demo, not as exploitation seen in the wild, but the proxy's strategic position continues to make it a prime target. ## What to Do Upgrade to **LiteLLM v1.83.14-stable** or later, the first release with the full fix set. Then, conduct a thorough 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`, as these 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 configuration. 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 a result of misplaced trust at every layer: the route gate trusted the caller-supplied field, the handlers trusted the route gate, and no one actually performed a crucial check.