The Token Was Invalid. The Gateway Let the Caller Through Anyway.

An authentication check that fails is supposed to be the end of the request. LiteLLM's MCP authentication handler had exactly that check, and for requests targeting MCP servers it had never configured for the alternative it was about to reach for, the check's own failure was not the end of anything.

What LiteLLM's MCP endpoint actually does

LiteLLM is an open source proxy and gateway for LLM API calls, widely deployed as the layer applications and agents call through rather than calling a model provider directly. Among its features, LiteLLM can front a Model Context Protocol Streamable HTTP endpoint, letting a caller reach a set of MCP servers an operator has configured behind LiteLLM's own proxy, so that one gateway mediates both model calls and MCP tool calls rather than an agent holding a separate credential for each. Ordinarily, a request to that endpoint is expected to carry a LiteLLM issued virtual key, which the handler validates the same way it would validate a key on any other route. LiteLLM also supports a second mode for MCP specifically, OAuth2 passthrough, meant for upstream MCP servers an operator has explicitly configured to accept a caller's own OAuth2 token directly rather than a LiteLLM key, so that server can perform its own authentication rather than delegating it entirely to LiteLLM's key store.

The fallback that replaced a failure with an empty identity

The vulnerability sits in what happened when the ordinary key check failed. LiteLLM's own key validation is the same mechanism that protects every other route the proxy serves, and it is meant to reject a request whose Authorization header carries a value that does not resolve to a valid, issued key. In versions before 1.84.0, when that validation raised an HTTPException with a 401 or 403 status on the MCP path, the handler's except clause did not propagate the rejection. It constructed an empty UserAPIKeyAuth object, the same type the handler would populate on a successful validation, and let the request proceed as though authentication had produced a result rather than failed to produce one. The condition that was supposed to gate this fallback, that the request's actual target MCP server was one an operator had configured for OAuth2 passthrough, was not checked before the fallback fired. A caller could send a request carrying a value in the Authorization: Bearer header that had never been issued by anything, one that would fail LiteLLM's key check on any ordinary route in exactly the way a fabricated credential is supposed to fail, and receive back not a rejection but a request that continued toward whatever MCP tooling LiteLLM had configured, carrying an identity object the handler itself had manufactured rather than validated.

What the fix actually restricts

BerriAI's fix, in LiteLLM 1.84.0, shipped in commit 73869f0faf7d11ee21adcb5f91b8c33a340b6c2c through BerriAI/litellm#26463, titled by its own author fix(mcp): tighten public-route detection and OAuth2 fallback gating. This record read the pull request and the fixing commit directly rather than inferring their content from advisory prose. The fix adds a helper, which this record's own reading names as gating the fallback on whether every one of a request's resolved target MCP servers is itself explicitly configured with auth_type set to oauth2, together with a companion helper that resolves which server or servers a request actually targets, from the URL path's own /mcp/{server_name} or /{server_name}/mcp shape, or from an x-mcp-servers header when one is present. A request whose target cannot be resolved this way, whose target is not configured for OAuth2, or whose target list is empty, now fails closed: the original authentication failure is allowed to terminate the request, exactly as it would on any other route, instead of being replaced by the anonymous fallback. The fallback still exists after the fix. What changed is that it is now scoped to precisely the configuration it was always supposed to require, rather than firing for any MCP request whose key check happened to fail.

A second, distinct fix in the same function

The same commit also tightens a separate check in the same request handling function, and this record treats it as separate rather than folding it into the OAuth2 fallback story it does not share a mechanism with. Before the fix, the handler treated a request as an unauthenticated public route, one exempt from the key check entirely, whenever the substring .well-known appeared anywhere in the request's URL, a check this record's own reading of the diff confirms was written as ".well-known" in str(request.url). A caller could append a value such as ?.well-known as a query string to an otherwise protected MCP route and have it read as a public, unauthenticated path regardless of what the path itself actually was. The fix narrows that check to request.url.path.startswith("/.well-known/"), so only an actual .well-known path prefix, not a query string or any other part of the URL a caller controls, can mark a request as public. This record found no separate CVE or GitHub Security Advisory identifier for this specific check, in its own search or in GHSA-7488-6r32-c95q's own text, which describes only the OAuth2 passthrough fallback. It is recorded here as supporting implementation evidence carried by the same fixing commit and the same function, not as a second vulnerability with its own canonical identity, and not folded into CVE-2026-59822's own described mechanism, which GitHub's advisory scopes to the OAuth2 fallback alone.

What CISA's 2 September 2026 KEV addition establishes, and what it does not

CISA added CVE-2026-59822 to its Known Exploited Vulnerabilities catalog on 2 September 2026, as one of seven vulnerabilities named in that day's addition, affecting several unrelated products; this record names only CVE-2026-59822 and does not carry detail about the other six forward from that batch. A KEV listing is CISA's own affirmative statement that it has evidence a vulnerability has been exploited, not a hypothetical or theoretical one. That is the entire, material change this record is built around: before 2 September 2026, CVE-2026-59822 was a disclosed, vendor confirmed and already patched vulnerability with no evidence of exploitation in this record's own search. After that date, it is the same vulnerability with a federal cybersecurity authority's own evidence of active exploitation attached to it.

The Authority Provenance ledger

Grantor. The operator running a LiteLLM deployment and its MCP proxy configuration, the party who decides which MCP servers are reachable through it and which of them are configured for OAuth2 passthrough. Nothing in the advisory or the fixing commit makes the model, the agent, or the network caller a grantor of any authority here.

Caller. A network requester able to reach the LiteLLM MCP Streamable HTTP endpoint, with no requirement that the caller hold any credential LiteLLM would otherwise recognize as valid.

Presented credential. A fabricated or otherwise invalid value in the Authorization: Bearer header, one that does not resolve to an issued LiteLLM key.

Credential validation. Fails, in exactly the way LiteLLM's ordinary key check is designed to fail on a fabricated credential on any other route.

Vulnerable identity transition. Under the vulnerable fallback, that failure is not propagated. The handler constructs an empty UserAPIKeyAuth object and treats it as a validation result, without first confirming the request's actual target MCP server was configured for the OAuth2 passthrough mode the fallback exists to serve.

Effective caller authority. Not legitimately established. The synthesized identity carries no claim this record found tracing back to any credential, grant, or configuration the operator actually issued to this caller.

Downstream surface. Whatever MCP tools and connected services an operator's own configuration exposed through that LiteLLM deployment. This record does not claim a specific tool or service beyond that; reach is configuration dependent and unestablished beyond what the advisory and the fix describe in general terms.

Mandate. Not established. Nothing in the advisory, the fixing commit, or this record's own reading describes the caller as holding any organizational basis to reach the MCP tooling the fallback exposed.

Scope. Configuration dependent, and not independently established beyond that a request could reach whichever MCP servers were configured behind the affected deployment.

Inherited assumption. The rest of the request path, once past the MCP authentication handler, treated the synthesized empty identity object as sufficient authorization to continue toward MCP tooling, the same way it would treat a genuinely validated one.

Challenge. The original authentication failure was the request's own challenge to the caller's claimed authority. The vulnerable fallback bypassed it rather than the caller ever answering it.

Revocation. Fixed in LiteLLM 1.84.0. A published workaround for operators who cannot upgrade immediately is to disable or block the affected MCP routes at a reverse proxy or gateway sitting in front of LiteLLM.

Recovery. Unknown. No incident specific evidence establishes what, if anything, needs to be recovered from any exploitation before the patch, in any specific deployment.

Active exploitation. Established by CISA's 2 September 2026 Known Exploited Vulnerabilities catalog addition.

Observed downstream actions. Unknown. Not established by the KEV listing, the advisory, or this record's own search.

The reusable failure, not the product

It would undersell this vulnerability to read it as LiteLLM specifically having a bug in one fallback path. The mechanism generalizes past this one gateway: a caller's identity failed validation, and a fallback constructed on the same code path treated that failure as though it were a result, an accepted, if minimal, principal able to continue toward capabilities a genuinely validated identity would have been checked against. Two principles this record thinks the evidence supports, without treating either as an industry standard or as language BerriAI itself uses: an authentication or authorization failure at an identity translation boundary, the point where a gateway decides what principal a request continues as, has to fail closed, terminating the request, rather than degrading into some other, still accepted, authority state; and an error path must never be more permissive than the success path or the no credential path it stands in for, because a fallback built to handle one narrow, correctly configured case will eventually be reached by a request the fallback's own designers did not have in mind.

Where this sits against what this desk has already argued

TrueFoundry's MCP Gateway put its approval decision at a network boundary an individual agent builder cannot skip, an argument about where an authorization decision lives. This record is not about where the decision lived; LiteLLM's decision already lived at the gateway, in the right place. It is about what the gateway did once that decision's own validation step failed, a layer TrueFoundry's own argument does not reach.

Salesforce's Headless 360 permission inheritance research showed an MCP integration carrying more reach than the task delegated to it required, a question about how far a legitimately established identity's authority should extend. LiteLLM's vulnerability precedes that question entirely: the identity reaching MCP tooling here was never legitimately established at all, only synthesized in place of a rejection.

The broader argument that authority has to be evaluated independently at the moment of execution, not assumed from an earlier instruction or grant is the family this record belongs to, extended to a boundary the corpus had not yet isolated on its own terms: the moment a gateway's own authentication check fails is itself an execution moment, and what a fallback does immediately after that failure is as much a part of the authority decision as the check that came before it.

What this does not establish

This record does not claim CVE-2026-59822 was exploited against any specific organization, that any specific MCP tool or connected service was reached, or that any specific data or credential was exposed. CISA's KEV catalog establishes evidence of active exploitation; it does not itself carry incident level detail, and this record found none independently. Nor does this record claim every LiteLLM deployment configured for MCP was reachable by an untrusted caller: whether a given deployment exposed its MCP Streamable HTTP endpoint to an untrusted network, and whether any of its configured MCP servers were themselves reachable for OAuth2 passthrough, are facts about that specific deployment's own configuration, not about LiteLLM generally.