LiteLLM CVE-2026-47101→40217: low-privilege user to admin and RCE

What is this?

On June 16, 2026, Obsidian Security publicly disclosed a chain of three vulnerabilities in LiteLLM, the widely deployed open-source AI gateway. Chained together, they form a CVSS 9.9 path that takes a default low-privilege user all the way to proxy_admin and then to remote code execution on the gateway host. The three CVEs are:

• CVE-2026-47102 — privilege escalation via missing field-level authorization on /user/update and /user/bulk_update. The user_role field is not protected from caller-controlled writes, so any user who can reach those handlers can promote themselves to proxy_admin.
• CVE-2026-47101 — authorization bypass: a non-admin can mint or update a virtual key whose allowed_routes are persisted as-supplied, granting route access — including admin-only routes — that the caller should never hold.
• CVE-2026-40217 — a custom-code guardrail sandbox escape. Admin-reachable routes compile and run admin-supplied Python inside a exec()-based sandbox that does not actually contain it, yielding server-side code execution.

Per Obsidian, the full chain is fixed in LiteLLM v1.83.14-stable (released May 2, 2026; disclosed publicly mid-June). The chain is distinct from the MCP-test-endpoint RCE CVE-2026-42271 that CISA added to its KEV catalog in June 2026 — there is no public KEV listing for the 47101/47102/40217 chain at the time of writing.

How it works

The chain is a textbook authorization failure, not a model attack. Each link removes one barrier:

1. Bypass route authorization (47101). LiteLLM trusts caller-supplied allowed_routes on key-management endpoints and stores them verbatim. A low-privilege account creates a virtual key referencing routes it has no business reaching.
2. Escalate to admin (47102). Reaching /user/update (or the bulk variant), the attacker writes the security-sensitive user_role field directly — self-promoting to proxy_admin, which unlocks full access to users, teams, keys, models and prompt history.
3. Execute code (40217). As admin, the attacker reaches the custom-code guardrail compile/test path and runs Python in a sandbox that fails to isolate, achieving RCE on the proxy process.

No payload is reproduced here, and none is needed to grasp the lesson: a “configuration” write that touches a role or a route is an authorization decision, and LiteLLM treated several of them as ordinary field updates. The recurring root cause is a route gate that consults user-controlled key state as a fallback grant, which inverts the authorization model.

Why it matters

An AI gateway is not a passive request router — it is control-plane infrastructure. Once the chain lands, Obsidian notes the attacker can reach host-level secrets such as LITELLM_MASTER_KEY, LITELLM_SALT_KEY and DATABASE_URL, plus provider credentials for OpenAI, Anthropic, Gemini, Bedrock, Azure and any other configured backend. In one position the gateway becomes a credential vault, an authorization broker, and a man-in-the-middle between agents and models.

The same research demonstrated a more AI-native consequence: a compromised gateway can rewrite model responses and steer downstream agents — including coding agents — toward attacker-chosen tool calls. That turns a server takeover into a supply-chain pivot against everything the gateway feeds. If you run LiteLLM in front of a fleet of agents, its blast radius is the union of every credential and every agent action it brokers.

Defenses

• Patch now. Upgrade to LiteLLM v1.83.14-stable or later, which Obsidian states closes the full chain. Confirm you are past the fixes for the separately tracked CVE-2026-42271 and CVE-2026-42208 as well.
• Rotate after exposure. If an unpatched instance was internet-reachable, assume secrets leaked. Rotate in priority order: provider API keys, LITELLM_MASTER_KEY and LITELLM_SALT_KEY, database credentials, then re-issue virtual keys.
• Get the gateway off the public internet. Treat LiteLLM like any other secrets-bearing control plane: private network only, behind authenticated ingress. The bulk of fast follow-on exploitation in this ecosystem hits exposed instances.
• Enforce field-level authorization on “config” writes. Anywhere user-supplied input sets user_role, allowed_routes, team ownership or policy metadata, gate it as an admin-only operation — not a routine update. Audit all key/user write handlers, not just the obvious one.
• Sandbox or disable custom-code guardrails. Run the proxy with least privilege, in a container with no host disk or shell access it does not strictly need, so an exec() escape buys the attacker as little as possible.
• Monitor tool calls and egress. Alert on self-service role changes, virtual keys minted with broad allowed_routes, and anomalous outbound traffic from the gateway. A compromised gateway steering agents will show up as unexpected tool invocations.

Status

CVE	Class	Effect	Fixed in
CVE-2026-47101	Authorization bypass	Unauthorized allowed_routes on virtual keys	v1.83.14-stable (full chain)
CVE-2026-47102	Privilege escalation	Self-promotion to proxy_admin via /user/update	prior to 1.83.10 affected
CVE-2026-40217	Guardrail sandbox escape	Server-side code execution via exec()	guardrail fix shipped; v1.83.14-stable
CVE-2026-42271 (separate)	MCP test-endpoint injection	RCE; in CISA KEV	1.83.7

The correct framing is not “another LiteLLM RCE.” It is that AI gateways are now execution-bearing control planes, and several of their privilege boundaries were enforced as ordinary data fields. Patch the chain, rotate what it could reach, and treat every role- or route-setting write as the authorization decision it actually is.