A Made-Up Bearer Token Gets You Into the MCP Tools: LiteLLM's Auth Bypass Is Being Exploited, and CISA's Deadline Is September 16

CISA added CVE-2026-59822 to its Known Exploited Vulnerabilities catalog on September 2 on evidence of active exploitation, with a September 16 remediation deadline for US federal agencies. The flaw is in LiteLLM's MCP Streamable HTTP endpoint: when API key validation fails, the OAuth2 passthrough fallback does not terminate the request but substitutes an empty UserAPIKeyAuth() object — so any fabricated Bearer token in the Authorization header gets through, with no valid LiteLLM key, account or prior access required. Every version before 1.84.0 is affected, scored 8.8 under CVSS 4.0. What an attacker reaches is the MCP tooling and the services connected to it, potentially exposing upstream LLM API keys, model outputs and backend credentials. One trap worth knowing: instances upgraded only to 1.83.0 to fix the earlier CVE-2026-35029 are still below the fixed version for this one.

The Fallback Was Written Facing the Wrong Way

The bug itself is short. The correct behavior when validation fails is to reject the request; instead the OAuth2 passthrough fallback treats failure as "no identity" and returns an empty `UserAPIKeyAuth()` so the request continues. The result is that any well-formed but fabricated Bearer token passes authentication and lands on the MCP routes. The blast radius comes from where LiteLLM sits. It's usually placed in front of several model providers as a single entry point, holding a whole row of upstream keys plus the virtual keys the proxy issues itself. So being bypassed doesn't cost you one credential, it costs you a layer of them. The attack chain described in reporting bears that out: attackers chained Starlette's CVE-2026-48710 with CVE-2026-42271 to get past authentication and drop XMRig miners, then went after `LiteLLM_ProxyModelTable` and `LiteLLM_VerificationToken` to harvest provider keys and proxy-issued virtual keys, and modified `authorized_keys` for persistence.

That the Entry Point Is MCP Deserves Its Own Note

Many teams only turned MCP routes on in the past six months, and their security review often still stops at "does the gateway itself authenticate," without covering the path they just bolted on. MCP tools frequently sit in front of internal systems — so once authentication is effectively absent, the attacker gains not just model calls but everything those tools were granted. A related signal: of the seven vulnerabilities CISA added to KEV in this batch, three point at AI infrastructure (LiteLLM, Kestra, and the Starlette-related one). AI-side middleware is becoming something people actively scan for, not just a research target.

Four Things to Do Today

Upgrade to **1.84.0 or later** — that number is the point. Instances bumped to 1.83.0 only to fix CVE-2026-35029 remain vulnerable, and plenty of operators will believe they are already patched. If you can't upgrade immediately, block `/mcp/` paths at the reverse proxy or API gateway, and turn MCP routes off entirely on internet-reachable instances. Inventory what permissions each connected MCP tool has been granted — that's what defines the boundary of the loss if this is used against you. Then investigate: if those routes were reachable from untrusted networks during the exposure window, go through the access logs, watching specifically for unusual key enumeration, virtual-key issuance and `authorized_keys` changes. As of September 5 public exploit code was still limited (one GitHub PoC repo, no identified Metasploit module or Nuclei template), but the basis for a KEV listing is that someone is already using it.

via: CISA KEV alert (2026-09-02), CVE-2026-59822 details, IONIX threat analysis, Sysdig on how fast LiteLLM's auth path was targeted