The Key Check Failed. The Session Opened Anyway

On Wednesday, CISA added CVE-2026-59822 to the Known Exploited Vulnerabilities catalog under the name "BerriAI LiteLLM Improper Authentication Vulnerability." The catalog entry describes it in one line: an unauthenticated attacker could establish an authenticated MCP session using an arbitrary Bearer token. Federal civilian agencies have until September 16.

No crypto outlet is likely to cover this, because LiteLLM is a Python proxy and not a blockchain. But LiteLLM is the gateway a very large number of organizations put in front of their model providers, and the endpoint in question speaks Model Context Protocol — the standard by which a model reaches out and does things. Every tool wired into that gateway sits behind the door this bug opened.

What the bug actually does

The mechanism, per the vendor advisory, is not a missing check. It is a check that ran, failed, and had its failure converted into a pass.

LiteLLM's MCP endpoint supports OAuth2 passthrough, so that credentials can be forwarded to an upstream MCP server that does its own authentication. To make that work, the handler had a fallback: when LiteLLM's own key validation failed, it substituted an empty UserAPIKeyAuth() object and carried on. An empty auth object is not a rejection — it is an anonymous session. So a request carrying a fabricated Authorization header would fail the key check, hit the fallback, and arrive at the MCP tooling as a valid, if unnamed, caller. From there, per the advisory, an attacker could enumerate and invoke MCP tools and reach the services exposed through them.

The CVE record files this under CWE-287, improper authentication, and scores it 8.2 (High) on CVSS v3.1. The vendor's own advisory scores it 8.8 under CVSS 4.0, with a vector reading VC:H/VI:L/VA:N — high confidentiality impact, low integrity impact, none to availability. That distinction matters later. All versions before 1.84.0 are affected; 1.84.0 fixes it.

The patch is more interesting than the bug

Reading the commit — 349 lines added across the MCP auth handler and its test file — the fix closes two doors, not one.

The first is the fallback itself, now gated: the OAuth2 passthrough only fires when every MCP server the request targets has been configured by an operator for OAuth2. Two new helper methods were added to work out which servers a request is aimed at and whether all of them qualify. For anything else, an auth failure stays a failure.

The second is quieter and, structurally, the more instructive one. The handler decided whether a route was public by testing whether the string ".well-known" appeared anywhere in the full request URL. Anywhere — including the query string, including the hostname. The patch replaces that with a check on the URL's path component alone, anchored to the start: request.url.path.startswith("/.well-known/"). A substring match on a reconstructed URL became a prefix match on a parsed path.

That is worth sitting with, because CISA added a second vulnerability to the catalog on the same day: CVE-2026-48710, an HTTP request smuggling flaw in Starlette, the Python web framework, described in the catalog as allowing an attacker to inject paths into the host portion — "leading to issues such as authentication bypass when the authentication depends on the reconstructed URL's path." Same failure mode. Same day. Different project.

One small grace note from the commit log: the patch closing an authentication bypass in an AI gateway lists a human maintainer and an Anthropic model as co-authors.

Fourteen days, not three

The deadline is a piece of reporting in itself. Since BOD 26-04 took effect in June — superseding the 2021 directive that gave every KEV entry the same clock — CISA no longer assigns one deadline to everything. It scores four variables: whether the asset is publicly exposed, whether the flaw is in KEV, whether exploitation can be automated, and whether the technical impact is partial or total control. The tiers run from three days plus mandatory forensic triage, at the top, down to fix-on-next-upgrade.

LiteLLM's MCP bypass got fourteen. It is in KEV and it is on internet-facing infrastructure, so the short clock was available — and CISA did not use it. The reading that fits is the one already written into the CVSS 4.0 vector: this bug yields high confidentiality impact but only low integrity impact. It is not the June flaw. It does not give you the server. It gives you the tool list, and whatever those tools can read.

Which is a smaller thing to lose, unless the tools are interesting.

Related The $500,000 isn't in the paper: what a study of 428 AI API routers actually found

Why a crypto desk is writing about a Python proxy

Because of where this class of software has ended up. Censys counted internet-exposed AI and LLM tooling rising more than 60 percent over nine months, to more than 294,000 public IP addresses, with LiteLLM among the faster-growing entries — its exposed instance count roughly doubling inside that window. Gateways went from a deployment convenience to a control point, which is why Microsoft's security team spent last week writing about AI gateways as targets rather than as plumbing.

The crypto-specific part is the blast radius, and it is entirely a function of what an operator wired up. An MCP gateway's exposure is the union of its tools. If a firm has connected a treasury dashboard, an exchange API, a signing service, or an agent's transaction queue to the same gateway that serves its models, then "enumerate and invoke MCP tools" is not an abstract phrase. It is a list of everything that agent was ever allowed to do, handed to whoever asked with the right-shaped header.

To be exact about what is not known: nothing in CISA's entry, the vendor advisory, or the CVE record names a victim, an industry, or a single crypto firm. KEV listing means CISA has evidence of exploitation in the wild. It does not say against whom, and no public reporting so far ties this bug to a digital-asset business. Anyone telling you otherwise is filling in a blank.

What is knowable is the exposure question, and it is answerable in an afternoon: is your gateway reachable from the internet, is it below 1.84.0, and what is on its tool list. The vendor's stopgap for anyone who cannot upgrade today is to block /mcp/ at the reverse proxy — which is a useful diagnostic on its own. If you cannot say what breaks when you do that, you do not know what is behind the door.