AI gateways were sold as a convenience layer — one OpenAI-compatible interface for every model on the market. This week, Obsidian Security turned that convenience into a worst-case scenario, showing how a default low-privilege account on a LiteLLM proxy can climb to full admin, execute code on the host, and silently rewrite the responses an AI agent acts on. The full chain rates CVSS 9.9. The proxy that brokered your calls is now the attacker.
How Three Bugs Compound Into a Full Server Takeover
Obsidian’s researchers chained three CVEs against LiteLLM, the open-source AI gateway maintained by BerriAI that brokers calls to more than 100 model providers behind a single API. The first link, CVE-2026-47101, is an authorization bypass: when an internal_user mints a virtual API key, LiteLLM stores the caller-supplied allowed_routes field without checking it against the user’s role, so a non-admin can issue themselves a key with allowed_routes: ["/*"]. The same unchecked write appears across multiple key-management endpoints, which is why BerriAI shipped the fix as three pull requests landing in v1.83.14-stable, listed by GitHub as released May 2.
With the route gate bypassed, the second link — CVE-2026-47102 — becomes reachable. The /user/update endpoint lets a user edit their own record but does not restrict which fields they can write, so a self-update with user_role: "proxy_admin" is accepted. VulnCheck scores it 8.7 under CVSS 4.0 and 8.8 under 3.1. The third link, CVE-2026-40217, is a sandbox escape in the Custom Code Guardrail: the production endpoints ran admin-supplied Python through exec() with a globals dict missing __builtins__, which Python silently re-injects, handing the payload __import__, open, and eval. A plain os.system call produced a reverse shell. X41 D-Sec independently found a parallel path on the /guardrails/test_custom_code playground endpoint that defeated a regex deny-list through runtime bytecode rewriting.
If you’re running LiteLLM on the data path between your engineers and Anthropic, OpenAI, or Bedrock, that means a single internal account — the kind handed out routinely to a junior engineer or a CI runner — can read every prompt, exfiltrate every provider key, and execute code on the box. The pattern here is depressingly familiar: a route gate trusted a caller-supplied field, the handlers trusted the route gate, and nobody actually checked. Expect more AI-infrastructure vendors to ship the same class of bug as they bolt admin consoles onto code that started life as an SDK wrapper.
Why a Compromised AI Gateway Is Worse Than a Stolen API Key
The loss inventory on a chain like this is brutal. A successful exploit exposes the master key, the salt key that decrypts stored credentials, and the database URL. Every configured provider key — OpenAI, Anthropic, Gemini, Bedrock, Azure — comes with it. Keys in config or env are plaintext; keys in the database are encrypted but recoverable with the salt. Every prompt and response transiting the gateway becomes readable, which in practice means PII, source code, internal tickets, and pasted secrets. If the same proxy doubles as a Model Context Protocol (MCP) or agent gateway, OAuth tokens and tool credentials are in scope.
The sharper risk is not exfiltration. It’s rewriting. The gateway sits on the wire between an AI agent and the model, and Obsidian demonstrated the attack against Claude Code routed through a compromised proxy: LiteLLM’s built-in callback mechanism — an extension point that fires on every request and never shows up in the admin UI — swapped the model’s response for a forged tool call and rewrote the safety-check context so the action read as approved. The developer typed one word, hello, and a reverse shell popped on the developer’s machine. This is not prompt injection. The model behaved correctly. The wire between the model and the agent lied.
If your team is shipping autonomous workflows — the kind covered in our writeup on AI agents vs AI automation — this is the failure mode worth losing sleep over. Imagine a customer-support agent that asks the model whether to issue a refund. A tampered callback can return “yes, run the refund tool” no matter what the model actually said. The auditor sees a clean transcript on the model provider’s side and a clean transcript on the agent’s side, and the only place the truth lived was the proxy in the middle. Expect regulators in regulated verticals to start treating AI gateways as Tier-0 infrastructure, with the same change-control posture as Active Directory.
How to Audit Your LiteLLM Deployment Today
The immediate move is to upgrade to v1.83.14-stable or later, the first release containing the full fix set. That closes the three-CVE chain, but it does not undo any compromise that already happened, and it does not change the design trade-off in LiteLLM’s MCP support: a proxy_admin can register stdio MCP servers that the proxy launches as local subprocesses, which means reaching admin is effectively reaching code execution. Obsidian reproduced a reverse shell that way on v1.88.0. A separate bug in the same machinery, CVE-2026-42271, was exploited in the wild and added to CISA’s KEV catalog earlier this month.
After upgrading, audit. Re-verify every account holding proxy_admin and treat that role as host-level access. Review every Custom Code Guardrail. Check the callbacks loaded from config.YAML under litellm_settings.callbacks — those never appear in the console and are exactly where a post-RCE attacker would hide persistence. Verify the integrity of the deployed code, not just the config. If you suspect exposure, rotate provider keys, database credentials, and any stored MCP tokens. Teams building AI-integrated software should also push the gateway out of the developer-laptop trust zone entirely; if a single hello can compromise a workstation, the proxy should not be reachable from one.
LiteLLM has been here before. A supply-chain compromise backdoored two releases on PyPI in March, and a critical SQL injection was exploited within 36 hours of disclosure in April. Obsidian frames the chain here as a disclosed flaw with a working demo, not exploitation seen in the wild — but the proxy’s position keeps making it a target, and the next one will not wait 36 hours.
FAQ
Q: What is LiteLLM and why is it a high-value target? A: LiteLLM is an open-source AI gateway maintained by BerriAI that exposes one OpenAI-compatible interface across more than 100 model providers. Because it brokers prompts, responses, and provider keys for every model behind it, a single compromise yields credentials, transcripts, and a man-in-the-middle position on every AI request the gateway serves.
Q: Which LiteLLM version fixes the chain? A: v1.83.14-stable, listed on GitHub as released May 2, is the first release containing fixes for all three CVEs (CVE-2026-47101, CVE-2026-47102, CVE-2026-40217). Older versions remain vulnerable to the full chain, and the separately disclosed CVE-2026-42271 was added to CISA’s KEV catalog after in-the-wild exploitation.
Q: Does upgrading remove the risk of a malicious proxy_admin?
A: No. LiteLLM’s stdio MCP support intentionally lets a proxy_admin launch local subprocesses, which means an admin account is functionally a code-execution account. The patches do not change that design, so admin role assignment must be treated as host-level access regardless of version.
Key Takeaways
- AI gateways now belong in the same blast-radius tier as identity providers — scope
proxy_adminaccordingly and audit callbacks that never surface in the UI. - Response-rewriting attacks bypass every safety review that lives inside the model; teams building agent workflows should plan for cryptographic response integrity, not just prompt-injection defenses.
- Vendors shipping admin consoles on top of SDK code will keep producing this class of authorization bug; static analysis of caller-supplied fields in privileged write paths is overdue.
- Regulated teams running gateways for healthcare workloads or other sensitive domains should isolate the proxy from developer laptops and rotate provider keys on a schedule, not only after incidents.
- LiteLLM’s three security incidents in 2026 suggest the project’s release cadence is outpacing its security review; expect competing gateways to lean into hardened-by-default builds as a differentiator within the next two quarters.