Low‑Privileged User Can Hijack LiteLLM AI Gateway via a Three‑Step Exploit Chain

Overview

LiteLLM, maintained by BerriAI, is a widely deployed open‑source AI gateway that proxies calls to more than 100 model providers through a unified OpenAI‑compatible interface. Obsidian Security disclosed a severe vulnerability chain that requires only a default low‑privilege account to achieve full administrator rights and remote code execution, with a combined CVSS score of 9.9.

Three Vulnerabilities in Detail

CVE‑2026‑47101: Authorization Bypass

The first flaw occurs when a regular user (internal_user) creates a virtual API key. LiteLLM stores the user‑provided allowed_routes field without verifying that it matches the user’s role. Because the field is also used as a fallback authorization check, a non‑admin can set allowed_routes: ["/*"] and gain access to all routes, including admin‑only endpoints. Similar unchecked writes appear in other key‑management endpoints, requiring three separate pull requests to fix.

CVE‑2026‑47102: Privilege Escalation

After bypassing route restrictions, the attacker reaches handlers that assume prior filtering. The /user/update endpoint lets a user edit their own record without restricting writable fields. By submitting user_role: "proxy_admin", the attacker upgrades to a full proxy administrator. The org_admin role can reach this endpoint via legitimate code paths, while the default internal_user must first exploit CVE‑2026‑47101. VulnCheck assigned CVSS 8.7 (v4.0) and 8.8 (v3.1).

CVE‑2026‑40217: Sandbox Escape

The third flaw resides in the Custom Code Guardrail, which compiles and runs administrator‑provided Python code via exec() without source‑level filtering. When exec() receives a globals dictionary lacking __builtins__, Python silently injects the full builtins module, exposing __import__, open and eval. A simple payload using os.system can obtain a reverse shell.

X41 D‑Sec independently discovered an additional path at the /guardrails/test_custom_code endpoint, bypassing a regex blacklist through runtime bytecode rewriting. Both paths ultimately achieve server‑side code execution.

What an Attacker Gains

Compromising the LiteLLM gateway exposes a broad attack surface:

Master key and salt key : can decrypt stored credentials.

Database URL : provides direct database access.

All provider keys : includes OpenAI, Anthropic, Gemini, Bedrock, Azure, etc.

All data flowing through the gateway : prompts, responses, PII, source code, internal tickets, pasted keys.

If the deployment also runs Model Context Protocol (MCP) or an agent gateway, OAuth tokens and tool credentials are additionally at risk.

More Dangerous Risk: Tampering Instead of Theft

The greater danger lies in the ability to tamper with traffic. Because the gateway sits between AI agents and models, an attacker who controls it can modify responses. Obsidian demonstrated an attack on Claude Code routed through a compromised LiteLLM instance. This is not a prompt‑injection; it leverages LiteLLM’s built‑in callback mechanism—an extension point triggered on every request that never appears in the admin UI. The malicious callback replaces the model’s response with a forged tool call and rewrites the security‑check context to appear approved.

In the demo, the developer typed a single word “hello,” and the attacker’s payload opened a reverse shell on the developer’s machine.

LiteLLM’s Troubled Times

This is not the first crisis for LiteLLM in 2026:

March 2026: supply‑chain attack inserted backdoors into two LiteLLM versions on PyPI.

April 2026: a critical SQL‑injection vulnerability was exploited within 36 hours of disclosure.

June 2026: CVE‑2026‑42271 (a vulnerability in the stdio‑MCP machinery) was observed in the wild and listed in CISA’s KEV catalog.

Obsidian notes that the current chain is fully disclosed with a working exploit, though no wild‑use cases have been observed yet. The gateway’s privileged network position makes it a perpetual target.

Remediation Recommendations

Upgrade to v1.83.14‑stable or later, the first release containing the complete fix set.

After upgrading, perform a thorough audit:

Re‑verify every account holding the proxy_admin role, treating it as host‑level access.

Review each custom code guardrail deployed on the proxy.

Inspect the callbacks loaded under config.yaml > litellm_settings.callbacks, as they never appear in the console and are a common post‑exploitation hideout.

Validate the integrity of deployment code, not just configuration files.

If compromise is suspected, rotate all provider keys, database credentials, and any stored MCP tokens.