LiteLLM's MCP Endpoint Trusted Any Bearer Token It Was Handed: One Header, Full Tool Access

The short version//

If you run LiteLLM as your AI gateway and it fronts any MCP servers, this one is about your tools, not just your API keys. CVE-2026-59822 (advisory published Jun 30, added to the KEV catalog Sep 2 with a Sep 16 due date): an unauthenticated attacker could open a fully authenticated MCP session using any fabricated Bearer token. The vendor rates it CVSS v4 8.8, all versions below 1.84.0 are affected, and the fix is a version bump — current PyPI release at time of writing is 1.99.0.

How an empty object becomes "authenticated"//

Here's the shape of it, in plain English:

• LiteLLM's MCP Streamable HTTP endpoint supports OAuth2 passthrough for upstream MCP servers — i.e., if your upstream tool server does its own OAuth, LiteLLM can hand the token through instead of validating against its own key system.
• When that path isn't taken, requests fall back to normal LiteLLM API-key validation.
• The bug: in certain conditions, when that fallback validation failed, the code didn't reject the request — it replaced the failed check with an empty UserAPIKeyAuth() object and carried on.

So the "authentication" for the session was literally an empty struct. Any request carrying a fabricated Authorization header — Bearer totally-made-up-token, honestly anything — got through as if it were authenticated. The vendor advisory classifies the impact directly: an attacker can list and call configured MCP tools and reach whatever services those tools are connected to. No valid LiteLLM key, no upstream OAuth token, nothing — just a header.

For non-gateway people: this is the classic auth fallback bug. The code was written for "we tried our auth, or we passed theirs through" — and the third case, "our auth ran and failed, but let's keep going anyway," wasn't handled. The empty object is the kind of thing that reads like a placeholder someone forgot to remove.

Why MCP makes this worse than a normal auth bypass//

A web-app auth bypass usually gets you data or admin pages. An MCP auth bypass gets you capabilities: your gateway's tool list is literally an inventory of things it can do — read files, hit APIs, write to databases, send messages, depending on what servers you've wired up. The attacker doesn't need to understand your LLM setup at all; they enumerate the tools and call them. It's a data-exfil and action story in one CVE, and CISA's KEV entry (CWE-287 improper authentication + CWE-306 missing authentication) says it's been exploited in the wild — though CISA's listing carries no attack details beyond that, so treat "exploited" as the official word rather than a specific narrative.

One more thing worth knowing: this is not LiteLLM's first KEV entry (May's CVE-2026-42208, an unauth SQL injection in the proxy key check, was a different flaw added to the catalog May 8). This one lives specifically in the MCP auth handler — which matters because every month, more homelabs wire more tools into their gateways. The attack surface is growing faster than most people's patch cadence.

What you should do//

1. Check your version. If LiteLLM is below 1.84.0, you're affected — and 1.84.0 (June) is the floor, not the target; current release on PyPI is 1.99.0.
2. Upgrade (pip install -U litellm or your equivalent) and restart the gateway. One version bump closes it.
3. If you can't upgrade tonight, apply the vendor's workaround: disable MCP routes, or block /mcp/ (and related MCP endpoints) at your reverse proxy. If your whole lab already sits behind one proxy — see our Caddy forward-auth + Authentik setup — this is a five-minute rule.
4. Audit what your tools can reach. The exploit didn't need to break into anything beyond the gateway, so ask: if a stranger had my MCP tool list for an hour, which of those tools could have read or written something they shouldn't? That's your real exposure assessment.