A Low-Privilege User Can Take Over the AI Gateway
Researchers have disclosed a vulnerability chain in LiteLLM, the widely deployed open-source AI gateway that brokers calls to more than a hundred model providers behind a single OpenAI-compatible interface. The full chain is rated CVSS 9.9, squarely in the critical range, and it lets a low-privilege user escalate to complete server takeover. For organizations that have quietly made LiteLLM the central chokepoint for their AI traffic, this is precisely the nightmare scenario: the one box that holds every provider key becomes the one box an ordinary user can seize.
The architecture is what makes the severity bite. An AI gateway exists to centralize credentials, routing, and policy so that application teams do not each manage their own OpenAI, Anthropic, Gemini, Bedrock, and Azure keys. That consolidation is operationally sensible and a security liability at the same time. A server takeover exposes every provider key the gateway holds, the master encryption and salt keys that decrypt its stored credentials, and every prompt and response passing through it. The very centralization that makes a gateway useful is what turns its compromise into a catastrophe.
Three Flaws That Combine Into Total Compromise
The chain begins with CVE-2026-47101, an authorization bypass. A regular user can generate a virtual API key, and LiteLLM stores the caller-supplied allowed_routes field without checking it against the user's role. That lets a non-admin mint a key with a wildcard route that reaches every endpoint, including admin-only ones. A companion flaw, CVE-2026-47102, lets a user self-elevate through the user update endpoint by setting their own role to proxy_admin, because the endpoint fails to validate the field. Together these collapse the boundary between ordinary user and administrator.
The chain ends with CVE-2026-40217, a sandbox escape in the Custom Code Guardrail feature, where admin-supplied Python is run through exec with no source-level filtering. As the researchers detailed, the exec call silently injects builtins, exposing import, open, and eval, which is more than enough to spawn a reverse shell. Separately, Horizon3.ai found that chaining with CVE-2026-48710, a Starlette host-header bypass, removes the authentication requirement entirely and pushes the combined severity to a maximum CVSS of 10.0. What starts as a routine low-privilege account ends as unauthenticated remote code execution.
Why AI Gateways Are Becoming High-Value Targets
This disclosure is a marker of a broader shift. As enterprises standardize their AI stacks, gateways and proxies like LiteLLM have become critical infrastructure that concentrate enormous value: not just API keys, but MCP tokens, OAuth credentials, and the plaintext content of every prompt and response. An attacker who lands on that server can read sensitive prompts, exfiltrate credentials for downstream cloud and model services, and even forge model responses in transit, quietly altering what users and applications believe the AI returned. That last capability is uniquely dangerous in an agentic world where automated systems act on model output.
We have watched the same logic play out with every category of middleware before it. Centralize secrets and traffic, and you create a target whose compromise is worth the effort to find a bug chain like this one. The difference with AI gateways is how new and fast-moving the codebases are, and how rarely they have been hardened or pen-tested before being pushed into production. Many teams deployed LiteLLM as an internal convenience and never reconsidered it as the privileged secrets vault it actually became.
Remediation and What to Audit Right Now
BerriAI, the LiteLLM maintainer, has shipped the complete fix set in version 1.83.14-stable, which GitHub lists as released on May 2. Upgrading is the first and non-negotiable step. But organizations that ran LiteLLM in an internet-accessible configuration between versions 1.74.2 and 1.83.6 should assume the worst and act accordingly: rotate every provider key the gateway touched, rotate the master and salt keys, and conduct a full AI infrastructure security audit rather than treating the upgrade as the end of the work.
Beyond patching, audit your proxy_admin accounts for any that should not exist, review every Custom Code Guardrail for unexpected logic, and check the callbacks defined in your config for tampering. The hardest truth here is that a gateway compromise can be invisible: forged responses and silent credential theft leave little trace. If you ran an exposed, vulnerable version, you cannot prove you were not hit by inspecting the gateway alone, which is exactly why credential rotation is the safe default rather than an overreaction.
The Hard Lesson for AI Infrastructure
The LiteLLM chain should prompt a wider reckoning about how AI infrastructure is being secured. These gateways were adopted for speed and convenience, often by platform teams under pressure to unblock AI projects, and the security review that any other secrets-bearing service would receive was frequently skipped. The result is a class of critical infrastructure that holds the keys to an organization's entire AI footprint while running code that is young, rapidly evolving, and only now attracting serious offensive research attention.
Our advice to technology leaders is to treat AI gateways with the same rigor as a secrets manager or an identity provider, because functionally that is what they are. Put them behind network controls so they are never internet-accessible without cause, scope user roles tightly, monitor for privilege changes, and subject them to the same patch discipline and penetration testing as any other crown-jewel system. The convenience of centralizing AI traffic is real, but so is the concentration of risk, and CVE-2026-47101 and its companions are a clear signal that attackers have noticed.
