LiteLLM Vulnerability Chain: What Security Teams Running AI Gateways Need to Do Now

If your team runs LiteLLM as an AI gateway, you have an urgent patch to ship. Obsidian Security published a LiteLLM vulnerability chain on June 15, 2026 that allows any low-privilege user on the proxy to reach full admin and execute code on the host. A separate RCE (CVE-2026-42271) was weaponised within days of disclosure and is now in CISA’s Known Exploited Vulnerabilities catalog. Together, these flaws put every API key your gateway holds at immediate risk.

Why AI Gateways Are High-Value Targets

LiteLLM is an open-source proxy that routes requests to more than 100 model providers behind one OpenAI-compatible interface. Teams use it to manage spend, enforce policies, and centralise logging across OpenAI, Anthropic, Azure, AWS Bedrock, and others. That centralisation is operationally convenient. But it also means a single compromised server can expose every provider credential the organisation uses, along with all the prompt and response data flowing through it.

Attackers understand this. According to Miggo.io, the window from disclosure to active weaponisation was as little as 36 hours. That suggests threat actors are monitoring these advisories closely and moving fast.

Inside the LiteLLM Vulnerability Chain

The three-CVE chain found by Obsidian Security starts from a default internal account. Also, each step is straightforward to script, and none requires interaction from a privileged user.

• Step 1 – Route bypass (CVE-2026-47101): LiteLLM lets any user create a virtual API key with a caller-supplied allowed_routes field. Setting this to ["/*"] gives the key access to admin-only endpoints. No server-side validation prevents it.
• Step 2 – Self-promotion to admin (CVE-2026-47102, CVSS 8.8): The /user/update endpoint does not restrict which fields a user can edit in their own record. Posting user_role: "proxy_admin" through the now-accessible admin route grants full administrator rights.
• Step 3 – Code execution (CVE-2026-40217): LiteLLM’s Custom Code Guardrail runs admin-supplied Python via exec() without source filtering. Python’s runtime silently makes os.system available. One guardrail rule with a reverse shell command is enough for a shell on the host.

The combined CVSS is 9.9 (Critical). So while each flaw is individually limited, the chain turns a low-privilege account into root-equivalent access on the gateway host.

What a Compromised Proxy Exposes

A successful exploit hands an attacker the master encryption key and the database credentials used to decrypt stored secrets. From there, every API key the proxy holds is readable. That includes keys for OpenAI, Anthropic, Azure, AWS Bedrock, and any other provider configured on the instance.

Beyond keys, the attacker can intercept prompts and responses in flight, which may include customer PII or proprietary model outputs. If the proxy is deployed as a Model Context Protocol gateway, OAuth tokens and tool credentials are at risk too. So the blast radius grows with the number of providers and downstream services connected to the instance.

The Separate Unauthenticated RCE

CVE-2026-42271 is a different vulnerability: command injection in two MCP REST test endpoints (POST /mcp-rest/test/connection and /mcp-rest/test/tools/list) in LiteLLM versions 1.74.2 to 1.83.6. Originally it required a valid (but low-privilege) API key. However, chaining it with CVE-2026-48710, a host-header validation bypass in the Starlette framework LiteLLM depends on, drops even that requirement. CISA confirmed active exploitation and set a June 22, 2026 remediation deadline for federal agencies.

Checking Your Exposure

Run pip show litellm on the host (or check your container image tag). Any version below 1.83.7 is vulnerable to CVE-2026-42271. Any version below 1.83.14-stable may be vulnerable to one or more steps in the LiteLLM vulnerability chain from Obsidian Security. If you have a self-hosted instance with an externally accessible API, assume test endpoints are exposed unless you have explicitly blocked them.

Earlier patches (v1.83.0) fixed CVE-2026-35030 and CVE-2026-35029 but not the later command injection issues. So partial upgrades leave real gaps. The only safe target is the current stable release.

Remediation Steps

Prioritise these actions in order:

• Upgrade to v1.83.14-stable (or the current latest stable) immediately. This is the single most important step.
• Rotate all provider API keys. Treat any keys stored in the proxy as potentially compromised if the instance was exposed or running a vulnerable version.
• Audit the proxy_admin user list. Remove any accounts you do not recognise, particularly those created with the proxy_admin role.
• Disable Custom Code Guardrails if not in active use. They are the exec-to-shell surface from CVE-2026-40217.
• Block or firewall the MCP REST test endpoints at the network perimeter if an immediate upgrade is not feasible. These endpoints should not be internet-accessible.
• Search access logs for requests to /mcp-rest/test/ paths and unusual POST /user/update calls containing user_role fields. These are your primary indicators of compromise.

Finally, if you have an internet-exposed deployment that ran any version before 1.83.7, rotate your provider keys today. Do this even if you have no evidence of compromise. The LiteLLM vulnerability chain and CVE-2026-42271 are both confirmed active, with the window from disclosure to weaponisation measured in hours.