LiteLLM Vulnerability Chain Lets Low-Privilege Users Take Over AI Gateway Servers

Summary

A critical vulnerability chain affecting the open-source LiteLLM AI gateway allows low-privilege users to escalate to full administrator access and execute arbitrary code on the server. This chain, rated CVSS 9.9, exposes sensitive provider keys, decryption secrets, and all prompts and responses passing through the gateway. The maintainer has released a fix in version v1.83.14-stable.

Full text

LiteLLM Vulnerability Chain Lets Low-Privilege Users Take Over AI Gateway Servers Swati KhandelwalJun 15, 2026Artificial Intelligence / Vulnerability 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. Found this article interesting? Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post. SHARE     Tweet Share Share Share SHARE  API Security, artificial intelligence, Cloud security, cybersecurity, LiteLLM, Open Source, privilege escalation, remote code execution, Vulnerability ⚡ Top Stories This Week Chrome V8 Zero-Day CVE-2026-11645 Exploited in the Wild - Patch Now Researchers Build Self-Replicating AI Worm That Operates Entirely on Local, Open-Weight Models Microsoft Defender RoguePlanet Zero-Day Grants SYSTEM Access on Updated Windows Anthropic Releases Claude Fable 5, Its Most Powerful AI Yet, With Cyber Safeguards Microsoft Patches Record 206 Flaws, Including Three Zero-Days and Critical RCE Bugs Ivanti, Fortinet, and SAP Release Patches for Multiple Critical Vulnerabilities Cybersecurity Stars Awards 2026: Winners Announced Across 95 Categories ThreatsDay Bulletin: Worm Code Leaked, AI Agent Phished, Claude Code Patch + 28 New Stories New GreatXML Exploit Bypasses Windows BitLocker via Recovery Partition XML Files Agentjacking Attack Tricks AI Coding Agents Into Running Malicious Code China-Linked Hackers Backdoored Linux Login Software to Hide for Nearly a Decade Critical Splunk Enterprise Flaw Lets Attackers Run Code Without Authentication U.S. Orders Anthropic to Suspend Fable 5 and Mythos 5 Access for Foreign Nationals Over 400 Arch Linux AUR Packages Hijacked to Deploy Infostealer and eBPF Rootkit ⭐ Featured Resources Get the 2026 Guide to Govern and Secure Enterprise AI Agents at Scale [Watch Demo] See Which Security Gaps Attackers Could Exploit First AI Can’t Stop Every Attack. Learn How Zero Trust Can Block What’s Unknown Have You Outgrown Your MDR? 7 Warning Signs Every CISO Should Check

Indicators of Compromise

• cve — CVE-2026-47101
• cve — CVE-2026-47102
• cve — CVE-2026-40217

Entities