LiteLLM MCP bypass: any bearer token calls your tools

LiteLLM's MCP endpoint had a fallback that turned a failed auth check into a successful one. CVE-2026-59822 lets an unauthenticated attacker open an authenticated MCP session using a bearer token they invented, then enumerate and call every tool your gateway exposes. CISA added it to the KEV catalog on September 2. Every version before 1.84.0 is affected.

What actually happened

LiteLLM's MCP Streamable HTTP endpoint supported OAuth2 passthrough so it could forward credentials to upstream MCP servers. When that passthrough path ran and LiteLLM's own key validation failed, the fallback replaced the failure with an empty UserAPIKeyAuth() object instead of rejecting the request. An empty auth object is still an auth object. The request proceeded.

The practical result: send Authorization: Bearer anything at the MCP endpoint and you get a session with access to the tool list and the tools themselves — and, through them, whatever those tools connect to.

Two details make this worse than a standalone high-severity bug.

First, exploitation is real. Wiz observed probing against model enumeration endpoints via honeypots, which is what reconnaissance looks like before someone bothers with the payload.

Second, it chains. Reporting on the KEV batch describes CVE-2026-59822 being combined with CVE-2026-42271 — the LiteLLM flaw we covered in July — to get from auth bypass to remote code execution, with Qilin ransomware operators using the pair. One unpatched gateway, two CVEs, full compromise.

Why your AI gateway matters for your business

MCP is the part people underestimate. An LLM proxy that only routes completions leaks tokens and money if it's breached. An LLM proxy wired to MCP servers is an action surface — it can read the database, hit the internal API, touch the file store, post to Slack, whatever you registered. The blast radius of "anyone can call your tools" is the union of every integration you connected, and most teams connected them one at a time without ever writing that list down.

Do three things. Upgrade to 1.84.0 or later — that's the fix, and it's not optional given active exploitation. Write down every MCP tool your gateway exposes and delete the ones nobody uses; the ones you keep should have their own credentials scoped to exactly what the tool needs, not a shared admin key. Put the gateway behind network controls so a public internet scan doesn't reach the MCP endpoint at all.

Then check your patch lag. LiteLLM has now had multiple credential-and-auth CVEs plus a PyPI supply-chain compromise this year. That's not an argument against using it — it's a fast-moving project doing a genuinely hard job. It is an argument for treating your AI gateway like production infrastructure with a named owner and an upgrade cadence, instead of a thing someone stood up during a spike.

Sources: CVE-2026-59822 advisory, CISA KEV alert, The Hacker News.