LiteLLM's MCP Auth Bypass Became the First MCP Flaw in CISA's KEV Catalog

2026-09-24 AI Vulnerabilities & CVEs by al-ice.ai Editorial

An AI gateway holds provider keys, virtual keys, routing policy, and the credentials of every tool behind it — which is why its authentication boundary failing open is worse than an ordinary login bug. CVE-2026-59822, an authentication bypass in LiteLLM's MCP Streamable HTTP endpoint, let an unauthenticated caller establish an authenticated MCP session with an arbitrary Bearer token and then list and call tools as though the gate had passed. CISA added it to the Known Exploited Vulnerabilities catalog on September 2, 2026, with a September 16 remediation deadline for federal civilian agencies — the first MCP-protocol flaw to enter the KEV. Every version below 1.84.0 is affected; 1.84.0 is the fix.

The flaw was reported by researcher yaaras and published as GitHub advisory GHSA-7488-6r32-c95q, "MCP Authentication Bypass via OAuth2 Passthrough Fallback." The advisory rates it 8.8 High on CVSS 4.0; NVD scores the same issue 8.2 on CVSS 3.1 — a half-point gap that means scanners disagreeing with each other about this finding is expected, not evidence either side is wrong.

A failed check fell through to a default identity

LiteLLM supports OAuth2 passthrough, where a token in the Authorization header is meant for an upstream MCP server rather than for LiteLLM itself. In the vulnerable code path, when local LiteLLM key validation failed, the fallback substituted an empty UserAPIKeyAuth() object instead of rejecting the request. An empty auth object is not the same thing as no auth object: downstream code reads it as a caller with no key limits attached — no budget, no allowed-models list, no team scoping — and the request continues with the permissions of nobody in particular, which in practice means the permissions of the gateway.

The shape of the bug is a one-branch error. The passthrough path should be entered because the server was configured for it, never because another check failed. Instead, a failed authentication check fell through to a default identity, and the failure itself became the credential. Confidentiality is the impact the advisory rates High, which is the right emphasis for a component sitting on top of provider API keys, tool credentials, and whatever the connected MCP servers can reach.

The same fix closed a second, undisclosed bypass

The remediating change is pull request 26463, "fix(mcp): tighten public-route detection and OAuth2 fallback gating," merged April 30 and shipped in the May 14 release. It changed two things, not one. Alongside the fallback gating, it narrowed a public-route check that used to ask whether the string .well-known appeared anywhere in the request URL — so appending ?.well-known to any MCP route marked it public. The advisory never mentions that second bypass. Anyone who read the advisory text rather than the diff and concluded the Bearer fallback was the whole exposure undercounted the fix.

The timeline carries its own lesson. The patch shipped May 14 — roughly seven weeks before the advisory and sixteen before the CISA listing. Version, not disclosure date, is what tells you whether you were exposed, and a scanner matching on advisory publication windows would have missed months of exposure on unpatched gateways.

Known-exploited, and chained to a 10.0

KEV listing means CISA has evidence of active exploitation — this is not a theoretical bypass. Wiz Research further described a chain in which CVE-2026-59822 combines with CVE-2026-42271, the Starlette unauthenticated RCE this site covered in June: skip authentication with the MCP bypass, then reach the command-injection test endpoint, for a combined CVSS 10.0. Horizon3.ai published proof-of-concept work on the chain in June. The pairing is a reminder that gateway flaws compose — an auth bypass plus any authenticated-only primitive elsewhere in the same process is a full compromise path, and LiteLLM's history (a three-CVE RCE chain in July among others) keeps supplying the second half.

Exposure measurement underscores the blast radius. A community survey of the public internet counted roughly 33,000 reachable LiteLLM gateways after the disclosure, and separate reporting found default master keys still answering on a measurable share of deployments. A bypass whose exploit is a fabricated header, aimed at a population of tens of thousands of internet-facing credential stores, is exactly the profile KEV exists for.

What defenders should do now

Upgrade to LiteLLM 1.84.0 or later and confirm the running artifact. The fix shipped in May; anything below 1.84.0 carries both bypasses. Verify the version inside the running container, not only the manifest.
Treat an exposed pre-1.84.0 gateway as compromised. Rotate LiteLLM master and virtual keys, upstream provider keys, and any tool credentials reachable through connected MCP servers. KEV-listed means assume active probing.
Change the default master key. A gateway that still answers to sk-1234 does not need a CVE to be owned; the bypass only made an already-common misconfiguration worse.
Reconcile scanner scores before triaging. Advisory CVSS 4.0 8.8 versus NVD CVSS 3.1 8.2 will surface as duplicate findings with different severities in some pipelines — deduplicate on CVE, not on score.
Review MCP access logs for fabricated-Bearer sessions. Hunt for MCP tool listing and invocation tied to tokens that were never issued, and for requests carrying ?.well-known in the query string.
Constrain the gateway process. Non-root user, minimal secret mounts, and egress policy covering what connected MCP servers can reach. Both halves of the Wiz chain end in "code runs as the gateway" — set that blast radius deliberately.

The pattern matches the Bifrost gateway failures disclosed this week: an AI gateway's management and tool surfaces assume a trusted local operator, then listen on a network. Here the fail-open was not an insecure default but a fallback with the wrong polarity — a failed check producing an identity instead of a rejection. Gateways are identity boundaries now, and every fallback path in their auth handlers deserves to be read as an authentication decision, because attackers will read it that way.

Sources: