By CISA confirmed active exploitation of CVE-2026-42271 in LiteLLM and set a June 22 federal remediation deadline. That deadline applies to government agencies under BOD 22-01, but if you run a LiteLLM proxy in any production environment, the deadline should feel personal. Qilin ransomware is already moving on unpatched deployments.
The timing matters because June 15 brought something more alarming than the command injection flaw CISA flagged weeks ago. Obsidian Security published a three-vulnerability chain that lets a default LiteLLM user — a viewer account, no special permissions — escalate to full proxy administrator and then execute arbitrary code on the gateway server. Every provider API key stored in that server becomes available to the attacker.
What LiteLLM Is (and Why It’s Worth Targeting)
LiteLLM is an open-source AI gateway. Teams use it to put a single OpenAI-compatible API in front of 100+ model providers — OpenAI, Anthropic, Google Vertex AI, AWS Bedrock, Azure OpenAI, and more. One endpoint, one key management system, one place to handle rate limiting, cost tracking, and load balancing across providers.
That centralization is exactly what makes it valuable to attackers. A compromised LiteLLM instance doesn’t just give you one API key. It gives you all of them, plus the master key, the database URL, and shell access to whatever is running on the host.
The Three-Step Chain
The chain discovered by Obsidian Security links three separate flaws in sequence. Each step is relatively simple. Together, they reduce a full server takeover to a matter of minutes from a default user account.
Step 1: Mint a Key With Admin Route Access (CVE-2026-47101)
LiteLLM lets users create virtual API keys and supply an allowed_routes field to restrict which endpoints that key can reach. The problem: LiteLLM persists whatever you put in that field without validation. A standard user can call /key/generate and set allowed_routes: ["/*"] — granting the resulting key access to every endpoint, including admin-only routes. The server accepts it and saves it.
Step 2: Promote Yourself to Admin (CVE-2026-47102)
With admin route access from the key you just minted, you can now reach /user/update. This endpoint lets users modify their own records. It doesn’t restrict which fields are editable. Send a self-update with user_role: "proxy_admin" and LiteLLM promotes your account to full administrator, no questions asked.
Step 3: Get a Shell (CVE-2026-40217)
As a proxy admin, you have access to the Custom Code Guardrail feature, which lets admins supply Python code for content filtering via the /guardrails/test_custom_code endpoint. That code runs through exec(). There is a regex filter intended to block dangerous operations, but it can be bypassed by rewriting function bytecode — a well-documented technique that accesses restricted Python built-ins. From there, arbitrary shell commands execute on the host.
Start as a viewer. End with a shell. The whole chain requires only a default user account to initiate.
The Unauthenticated Variant
CVE-2026-42271 is a command injection flaw in LiteLLM’s MCP preview endpoints (/mcp-rest/test/connection and /mcp-rest/test/tools/list). These endpoints accept a full MCP server configuration, including a command field for stdio transport. That command field passes to the host OS without sanitization. An attacker with any valid API key can run arbitrary binaries on the server.
On its own, that requires a credential. Chained with CVE-2026-48710 — the Starlette “BadHost” host-header authentication bypass we covered in May — the credential requirement disappears. Unauthenticated remote code execution. CVSS 10.0. This is the variant CISA flagged as actively exploited, attributed to Qilin ransomware with medium confidence.
What’s Actually at Risk
A successful attack against a LiteLLM gateway doesn’t hand an attacker one API key. It hands them everything the gateway holds:
- Provider API keys for every connected service (OpenAI, Anthropic, Google, Bedrock, Azure)
- LiteLLM master key and salt key
- PostgreSQL connection string and database credentials
- Full shell access to the host server
Enterprise LiteLLM deployments often run with high API billing limits across multiple providers. Key theft means quota exhaustion attacks and direct financial exposure, in addition to the risk of every AI workflow being intercepted or manipulated.
Patch and Remediation Steps
The fix is available. LiteLLM v1.83.14-stable addresses the three-CVE chain. Starlette v1.0.1 patches CVE-2026-48710. Both updates are needed to close the unauthenticated RCE path.
Patching alone isn’t enough if you’ve been running a vulnerable version. Treat all provider keys as potentially compromised:
- Upgrade to LiteLLM v1.83.14-stable and Starlette v1.0.1
- Rotate all provider keys — revoke and regenerate at every upstream provider (OpenAI, Anthropic, Google, AWS, Azure)
- Audit proxy_admin accounts — remove any accounts you don’t recognize; CVE-2026-47102 may have created unauthorized admins without your knowledge
- Disable Custom Code Guardrails if not actively in use (removes the
exec()attack surface from CVE-2026-40217) - Block MCP REST test endpoints at the network layer if an immediate upgrade isn’t feasible:
/mcp-rest/test/connectionand/mcp-rest/test/tools/list
After rotation, confirm old keys are invalidated at the upstream provider level — not just removed from LiteLLM’s configuration. The Hacker News has additional technical detail on the chain for teams doing a deeper post-incident review.
AI Infrastructure Is the New Attack Surface
The LiteLLM chain follows a pattern that’s accelerating. LangGraph’s checkpointer RCE and the Spring AI vector store vulnerability both landed this week. AI infrastructure components — gateways, agent frameworks, vector stores — are now high-value targets because they sit between applications and sensitive model API credentials.
The June 22 CISA deadline is for federal agencies. Qilin ransomware is not limiting activity to .gov networks. If your LiteLLM deployment is internet-reachable and unpatched, the urgency is the same.
