Critical LiteLLM Flaw Chain Lets Low-Privilege Users Hijack AI Gateways

Researchers at Obsidian Security have disclosed a three-vulnerability chain in LiteLLM, a widely deployed open-source AI gateway that brokers calls to more than 100 model providers behind a single OpenAI-compatible interface. By chaining the bugs, a default low-privilege account can escalate to full proxy admin and execute arbitrary code on the underlying server. Obsidian rates the full chain CVSS 9.9, placing it firmly in the Critical range. A successful takeover exposes the master key, the salt key that decrypts stored credentials, the database URL, and every configured provider key for OpenAI, Anthropic, Gemini, Bedrock, Azure, and the rest, along with every prompt and response transiting the proxy. BerriAI, the project maintainer, shipped the complete fix set in LiteLLM v1.83.14-stable, released May 2, and organizations should upgrade immediately. Admins can also use a SSL/TLS checker to verify the gateway's external surface and a port scanner to confirm no stray services are exposed alongside the proxy.

The first link is CVE-2026-47101, an authorization bypass rooted in the virtual API key generation endpoint. When an internal_user mints a key, LiteLLM stores the caller-supplied allowed_routes field without validating it against the user's role. The proxy not only uses the field to restrict access but also treats it as a fallback grant, so a non-admin can set allowed_routes: ["/*"] and reach every route, including admin-only ones. The same unchecked write appears across the other key-management endpoints, which is why the fix required three separate pull requests. With the route gate neutralized, the second bug, CVE-2026-47102, becomes reachable. The /user/update endpoint lets users edit their own record but imposes no field-level restrictions, so a self-update with user_role: "proxy_admin" is accepted and saved, promoting the caller to full proxy admin. VulnCheck scored the privilege escalation 8.7 under CVSS 4.0 and 8.8 under 3.1. Notably, an org_admin can reach this endpoint through an intended code path with no bypass, while a default internal_user needs CVE-2026-47101 to get there.

The third link is CVE-2026-40217, a sandbox escape in the Custom Code Guardrail that compiles and runs admin-supplied Python. The production endpoints passed the code through exec() with no source-level filtering, and because exec() receives a globals dict without __builtins__, Python silently injects the full builtins module, handing the payload access to __import__, open, and eval. A trivial os.system call was enough to drop a reverse shell. A separate path on the /guardrails/test_custom_code playground endpoint, found independently by X41 D-Sec, defeated a regex deny-list via runtime bytecode rewriting, and both paths ended in unauthenticated server-side code execution.

The blast radius is wide because LiteLLM is a chokepoint for AI traffic. A full chain not only hands an attacker the keys to dozens of model providers but also the decryption material for every stored secret on the instance, meaning lateral movement into downstream SaaS accounts is trivial. Security teams running LiteLLM should patch to v1.83.14 or later, rotate every master key, salt, and provider credential after the upgrade, and audit virtual key records for any wildcard allowed_routes entries created before the fix landed. Operators worried about credential exposure on the wider internet can run a email breach checker against admin accounts and a password checker on any reused credentials to limit follow-on intrusion risk.