LiteLLM MCP auth bypass joins CISA's exploited list; fix requires 1.84.0, not 1.83.9

CISA added CVE-2026-59822, an authentication bypass in LiteLLM's MCP endpoint, to its Known Exploited Vulnerabilities catalog on 2 September 2026, a listing that signals confirmed attacker use. According to a post on dev.to (originally published on mcpscore.dev), the flaw let through any request carrying a bearer token — the token did not have to be valid — and it is closed only in LiteLLM 1.84.0.

How the bypass worked

LiteLLM sits between applications and model providers, and between agents and MCP servers. Its MCP endpoint validates the Authorization header against LiteLLM's own API keys. Because some upstream MCP servers — Atlassian is named as an example — expect their own OAuth token in that same header, LiteLLM added a fallback: when the header did not match a LiteLLM key, it treated the value as an upstream token and passed it along.

The fallback ran for every server, not just those configured for OAuth. In effect, a failed key check produced an anonymous session instead of a rejection, so a fabricated header could list and invoke every tool reachable through the gateway. The 1.84.0 fix applies the fallback only when every server the request targets is configured for OAuth, and it rejects the request when the target is unknown.

Why upgrading to 1.83.9 is not enough

October coverage of two other LiteLLM vulnerabilities — CVE-2026-59823, a server-side request forgery via user_config fixed in 1.83.9, and CVE-2026-35029, a privilege escalation via the config endpoint fixed in 1.83.0 — spread the advice to upgrade to at least 1.83.9. Per the dev.to post, that advice leaves the MCP bypass open: CVE-2026-59822 affects every release before 1.84.0, so versions 1.83.9 through 1.83.14 remain exposed. It is also the only one of the three on CISA's catalog.

The spec is unambiguous

The MCP authorization specification has required, since its 18 June 2025 version and unchanged in the 28 July 2026 revision, that invalid or expired tokens receive an HTTP 401 response. A server that successfully answers a request holding a token it never issued has not merely chosen a wrong status code: its authentication check either never ran, or ran and was ignored. The cause sits inside the server, but the symptom is visible on the wire.

A one-request check

mcpscore 1.25.0 ships a rule, auth_invalid_token_rejected, built on exactly that observation. It sends a tools/list request with a fabricated bearer token — a fixed prefix plus a random UUID. Any 2xx response fails the rule at high severity. A 401 or 403 passes, as does another 4xx if the WWW-Authenticate header carries error="invalid_token" under RFC 6750, a carve-out added because GitHub Copilot's MCP server rejects malformed tokens with a 400. Anything else, such as a 404, a redirect, a rate limit or a 5xx, is skipped. The check is read-only: it issues no tools/call, never follows a redirect with the token, and closes any session a server opens anyway.

The mcpscore team says it ran the rule against auth-gated production servers including Asana, Linear, Notion, Sentry, Stripe and GitHub Copilot before release; all refused the fabricated token.

The check has limits. A server can still accept a real token minted for a different service, forward client tokens to an upstream API, or grant more scope than a token carries — the spec forbids all three, and none is visible from outside, so catching them takes code review and gateway policy. The rule also needs a baseline refusal: a server that answers a tokenless request with a 500 rather than a 401 challenge cannot be tested.

Why it matters

This bug is bigger than LiteLLM. The failure mode — a failed authentication check silently degrading into a default identity — is one any MCP server can ship, and the spec's 401 requirement gives it a precise, externally testable signature. Gateways compound the exposure: one fallback in a single auth path exposed every MCP server connected behind it at once, along with the services those servers reach. Treat LLM and MCP gateways like the identity infrastructure they have effectively become — patch them when advisories land, keep them off the public internet unless they must be there, and make sure a request that clears the gateway is still refused by the server behind it. The new mcpscore rule covers part of MCP07, insufficient authentication, in the OWASP MCP Top 10.