al-ice.ai

LiteLLM Three-CVE RCE Chain — Default User to Full AI Gateway Compromise in Two Seconds

AI CVEs by al-ice.ai Editorial

AI relevance: LiteLLM is one of the most widely deployed open-source LLM proxies — a compromise of the gateway is a supply-chain compromise of every AI application downstream of it, including coding agents like Claude Code, Cursor, and Copilot Chat.

What happened

  • SecureLayer7 researchers disclosed a chain of three CVEs in LiteLLM's management API that collapses the gap from "default internal user" to "full RCE on the LiteLLM host" in under two seconds with a single Python script.
  • CVE-2026-47101 (wildcard key escalation): Any internal_user — the lowest role, created via /user/new — can issue themselves a virtual key with allowed_routes: ["/*"], bypassing all route-level authorization checks.
  • CVE-2026-47102 (mass assignment self-promotion): Using the wildcard key, the attacker POSTs to /user/update with user_role: "proxy_admin" and is promoted — the endpoint never restricts which fields a self-update can modify.
  • CVE-2026-40217 (fake sandbox RCE): The attacker uploads a "custom guardrail" containing __builtins__['__import__']('os').system(...). The exec(source, {}) call silently injects full builtins into the empty globals dict — the "sandbox" never existed. Code fires at compile time, before the guardrail is ever invoked.
  • From the resulting shell, the attacker gains: all provider API keys (OpenAI, Anthropic, Bedrock, etc.), the full virtual-key database, audit logs, and the callback system that can rewrite LLM responses in flight.
  • The callback access is the critical second-order impact: an attacker can inject forged tool calls into LLM responses flowing back to downstream coding agents, turning the compromised proxy into a persistent man-in-the-middle for every AI-using application.
  • CVSS: 9.9. Affected: all LiteLLM < v1.83.10-stable (full chain); v1.83.10–v1.83.13 (partial — CVE-2026-47102 patched but wildcard key + bytecode bypass still work). Fixed: v1.83.14-stable (April 25, 2026).
  • The attack requires only that the attacker hold any internal_user account — no admin interaction, no user interaction, no special scopes. Three POST requests from the same source within seconds is the entire wire signature.

Why it matters

LiteLLM sits in front of dozens of model providers and mediates every request from internal applications to the models. It holds provider secrets, the configuration database, and the callback infrastructure that can modify every response in flight. A compromise here isn't a single-application vulnerability — it's a supply-chain compromise of every AI-using application downstream. Organizations that treat LiteLLM as "just a proxy" may not realize it's the single funnel for all AI traffic and secrets.

What to do

  • Upgrade immediately to LiteLLM v1.83.14-stable or later. The wildcard key and mass assignment flaws are fully patched.
  • Audit your LiteLLM user table — check for any internal_user accounts that were promoted to proxy_admin without authorization.
  • Rotate all provider API keys stored in LiteLLM if you were running a vulnerable version. Assume they were exfiltrated if you cannot prove otherwise.
  • Review custom guardrails for any entries containing __builtins__, exec(), or os.system() calls.
  • Monitor callback configurations for unauthorized additions — a malicious callback can persist even after the initial exploit.
  • Network-segment LiteLLM — the management API should not be reachable from untrusted networks. Apply the same segmentation you'd use for a secrets vault.

Sources