A low-privilege account by default on a LiteLLM broker can escalate to full administrator and execute code on the server by exploiting three vulnerabilities, researchers at Obsidian Security.
See also: Mercor hit by supply chain attack related to LiteLLM

LiteLLM is a widely used open source AI gateway that manages calls to over 100 model providers through a single OpenAI-compatible interface. Taking over a server exposes every provider key it holds, the secrets that decrypt its stored credentials, and every prompt and response that passes through it.
Obsidian rates the full chain at CVSS 9.9, in the Critical category. BerriAI, the maintainer, included the full set of fixes in LiteLLM v1.83.14-stable, released on May 2. Users are advised to upgrade to this version or later to close the chain of three CVEs.
The first vulnerability is CVE-2026-47101, an authorization bypass. When a regular user (internal_user) creates a virtual API key, LiteLLM stores the allowed_routes provided by the caller without validating it against the user's role.
This field is intended to limit what a key can do. However, the broker also treats it as a fallback grant, allowing a non-administrator to create a key with allowed_routes: [“/*”], a wildcard that has access to any route, including those reserved for admins only. The same uncontrolled entry appears on other key management endpoints, so the fix required three pull requests.
Bypassing the route gate makes the operators behind it accessible. Many of them assume that the gate has already performed the necessary screening, leading to two potential exploitation paths.
See also: Pardus Linux: Chain of vulnerabilities allows complete system takeover

The second vulnerability is CVE-2026-47102, privilege escalation. The /user/update endpoint allows a user to edit their own file but does not restrict which fields they can modify. A self-update with user_role: “proxy_admin” is accepted and saved, promoting the caller to full proxy administrator. An org_admin can access this endpoint via a legitimate code path without any workaround. A default internal_user can reach it after CVE-2026-47101. VulnCheck rates it 8.7 under CVSS 4.0 and 8.8 under 3.1.
The other vulnerability is CVE-2026-40217, a sandbox escape in Custom Code Guardrail, which compiles and executes Python code provided by the administrator. Production endpoints executed the code via exec() without source-level filtering. When exec() receives a globals dictionary without __builtins__ , Python silently imports the full builtins module, providing access to __import__ , open , and eval . A simple payload calling os.system was sufficient for a reverse shell.
A separate route to the /guardrails/test_custom_code playground endpoint, discovered independently by X41 D-Sec, bypassed a regex blacklist via bytecode rewriting at runtime. Both routes led to server-side code execution.
LiteLLM acts as a bottleneck, so the impact is significant. A full chain exposes the master key, the salt key that decrypts the stored credentials, and the database URL. It also reveals every configured provider key for OpenAI, Anthropic, Gemini, Bedrock, Azure, and others.
See also: Vulnerability in LiteLLM leads to unauthenticated RCE

Keys in the configuration or environment are stored in plain text. Keys in the database are encrypted but can be recovered with the salt key. Everything transmitted through the gateway, including prompts and responses, becomes readable, which in real deployments could contain PII, source code, internal tickets, and sensitive information.
🔒 Protect your privacy with Proton VPN
Swiss VPN from the creators of Proton Mail — strict no-logs policy, strong encryption, and built-in NetShield that blocks ads, trackers, & malware.
- ✔ No-logs, based in Switzerland (except 14-Eyes)
- ✔ NetShield: blocks ads, trackers & malicious domains
- ✔ Covers all devices — free version available
The link is an affiliate link — SecNews may receive a commission at no additional cost to you. It does not affect the independence of our article writing.
