Breaking LiteLLM: From Low-Privilege User to Admin and RCE (CVE-2026-47101, CVE-2026-47102, CVE-2026-40217)

SaaS Security

Platform

Pricing<br>Company

Resources

Company

Free Trial<br>Get a Demo

Breaking LiteLLM: From Low-Privilege User to Admin and RCE (CVE-2026-47101, CVE-2026-47102, CVE-2026-40217)<br>Obsidian Security found three chained LiteLLM CVEs that let a default low-privilege user reach admin access and RCE (CVSS 9.9). We also demonstrate how a compromised gateway can inject arbitrary tool calls to further compromise downstream agents like Claude Code. Full breakdown and the fixes.<br>Published:<br>June 11, 2026

Updated:<br>June 11, 2026

TL;DR<br>Security researchers at Obsidian Security uncovered multiple vulnerabilities in LiteLLM, a widely deployed open-source AI gateway. Together, they form a CVSS 9.9 exploit chain: a default low-privilege user can gain administrator access and execute arbitrary code on the LiteLLM server.<br>The findings break down as follows:<br>CVE-2026-47101 — Authorization bypass via unvalidated allowed_routes written through key-management endpoints such as /key/generate and /key/update. LiteLLM persists caller-supplied route permissions as-is, allowing a non-admin to mint a key with access to arbitrary routes, including admin-only ones.<br>CVE-2026-47102 — Privilege escalation via missing field-level authorization on the /user/update and /user/bulk_update endpoints, where user_role is not protected from caller-controlled updates. Any user who can reach these handlers can promote themselves to proxy_admin: an org_admin can do it directly, and a default internal_user can do it after CVE-2026-47101.<br>CVE-2026-40217 — Sandbox escape in the custom-code guardrail. The /guardrails CRUD endpoints run user code with exec() while leaving __builtins__ available. Separately, X41 showed that /guardrails/test_custom_code’s regex deny-list can be bypassed with runtime bytecode rewriting. Both paths lead to server-side code execution.<br>We responsibly disclosed these issues to BerriAI in February. BerriAI shipped fixes across subsequent releases, with the full set of fixes included in LiteLLM v1.83.14-stable (released 2026-04-25). Upgrading to that release or later closes the entire chain.<br>Why this matters: the blast radius<br>As an AI gateway, LiteLLM sits at a critical chokepoint in the modern AI stack. A successful chain reaches:<br>Host-level secrets. LITELLM_MASTER_KEY (admin credential), LITELLM_SALT_KEY (used to decrypt DB-stored credentials), DATABASE_URL (database username/password), and anything else on the host.<br>LLM provider credentials. Every configured provider key is exposed: OpenAI, Anthropic, Gemini, Bedrock, Azure, and more. Keys in config/env are plaintext; keys in the database are encrypted, but recoverable using the salt key above.<br>MCP and agent credentials. Once LiteLLM doubles as an MCP or agent gateway, the blast radius expands again: OAuth tokens, SaaS API keys, internal tool credentials, and agent service-account tokens are now in scope too.<br>Conversation content. Everything sent through the gateway becomes readable: prompts, responses, and any logs it keeps. In real deployments this is where PII, internal tickets, source code, customer data, and pasted secrets all end up.<br>But the most consequential reach isn't what an attacker can read — it's what they can control. The gateway sits between an AI agent and the model. Compromise lets an attacker tamper with responses in transit: rewrite what the agent sees, mislead users, or hijack its execution flow into downstream shell access, arbitrary file reads, browser actions, or other tools the agent is allowed to touch.<br>At that point, the gateway is no longer plumbing. It is the steering wheel for the AI agent. Once it's compromised, everything downstream of it goes where the attacker steers.<br>Motivation<br>By now, you have probably seen the demos: a hidden instruction in a webpage, document, ticket, or tool response quietly rewrites an agent’s execution flow. That is indirect prompt injection, one of the canonical AI-native security problems. The attack tricks the LLM with carefully crafted input so it produces a response that makes the agent act as the attacker wants.<br>That raised a question: could an attacker hijack the response directly? So we looked at the gateway in front of the model, to see whether it could be fully compromised. Open-source gateways like LiteLLM were the obvious target: popular, widely deployed, and the earlier supply-chain incident had already made clear how important it had become to AI infrastructure.<br>AI is moving fast, and much of the stack is inheriting old web bugs along the way. Our previous work on Langflow and Flowise showed exactly that. The AI layer is new, but many of the failure modes are not.<br>Let's look at LiteLLM.<br>Deep dive into LiteLLM<br>LiteLLM is an open-source AI gateway that gives applications a single OpenAI-compatible interface for calling 100+ LLM providers. Developers can import it as a Python SDK, or deploy...