CISA Adds LiteLLM's MCP Auth Bypass to KEV: Any Bearer Token Was Enough

On 2 September 2026 the U.S. Cybersecurity and Infrastructure Security Agency added CVE-2026-59822 to its Known Exploited Vulnerabilities catalog as the "BerriAI LiteLLM Improper Authentication Vulnerability", one of seven flaws in that day's batch. The bug is in LiteLLM's MCP Streamable HTTP endpoint: when validation of a LiteLLM key failed, the OAuth2 passthrough fallback substituted an empty UserAPIKeyAuth() object instead of rejecting the request, so any fabricated Authorization Bearer header opened an authenticated MCP session. An attacker who reached that endpoint could list and call every MCP tool the gateway was configured with, and through those tools reach the services behind them. Every version before 1.84.0 is affected, and federal civilian agencies were given until 16 September to remediate. This record — the KEV listing for LiteLLM's MCP authentication bypass — is one entry in the OrcaRouter AI Incident Archive, which holds the full record set and this incident's neighbouring entries.

The reason a bug in a proxy matters more than its CVSS score suggests is what sits behind the proxy. Wiz's threat-research team puts it directly: "A LiteLLM proxy can hold keys for every model provider it routes to, including OpenAI, Anthropic, Azure, and Gemini. It may also run with cloud IAM permissions and connect to internal services through MCP tool servers. A single compromise can give an attacker access to the credentials and services downstream of the proxy, not just the proxy itself." Wiz Research says it discovered the flaw, and Wiz's honeypots later recorded attempts to use it.

The mechanism: a failed check that returned a valid session

BerriAI's own advisory, GHSA-7488-6r32-c95q, describes the defect in two sentences: "The MCP auth handler supported OAuth2 passthrough for upstream MCP servers, but the fallback path could replace failed LiteLLM key validation with an empty UserAPIKeyAuth() object. This allowed requests with a fabricated Authorization header to reach MCP tooling without a valid LiteLLM key." The important word is fallback. The code had a branch for deployments that pass an upstream MCP server's OAuth token straight through, and when a LiteLLM key failed to validate, that branch handed back an empty authentication object rather than an error.

An empty authentication object is not the same as no authentication object. Downstream code saw a successfully constructed UserAPIKeyAuth and proceeded, with no tenant, no user and no scope attached to it. Wiz's write-up is blunter about the practical consequence: "when token validation fails, rather than rejecting the request, the server returns an empty UserAPIKeyAuth() object with no restrictions. Any Bearer token (even just a single character, e.g., x) grants full MCP access."

What that buys an attacker is a menu. The MCP protocol exposes a tool listing, so a session that authenticates returns the names and schemas of every tool the gateway has been configured to reach — databases, code repositories, internal APIs, in Wiz's examples. The vendor advisory states the effect plainly: "An attacker could use this to list and call configured MCP tools and access connected services exposed through MCP." The tool calls then execute with whatever authority the proxy itself holds toward those backends, which is the credential-concentration problem Wiz describes.

A fix in May, a CVE in July, a federal deadline in September

The dates do not line up the way a reader might assume, and the gaps are the interesting part. LiteLLM 1.84.0 — the first version the advisory names as patched — was uploaded to PyPI on 14 May 2026, according to the package index's own release metadata. The CVE identifier was reserved with the CVE Program on 7 July 2026 and the record published the following day, 8 July; the OSV entry PYSEC-2026-3479 followed on 23 July. The KEV listing came on 2 September, with a remediation deadline of 16 September.

Two things follow. First, the patched build was public for more than three months before CISA listed the flaw as exploited — so the organisations the deadline bound had a working upgrade available the whole time, and the KEV addition was not the moment a fix appeared. Second, the version gap has widened since: the current LiteLLM release on PyPI is 1.106.5, uploaded on 27 October 2026. A deployment still sitting on anything below 1.84.0 is now more than twenty minor releases behind, not merely one patch short.

What the listing establishes, and what it does not

CISA's alert for the batch says the additions are made "based on evidence of active exploitation", and the catalog's machine-readable entry for CVE-2026-59822 carries a date added of 2 September 2026, a due date of 16 September 2026, a known-ransomware-campaign-use value of "Unknown", and two weaknesses: CWE-287 (improper authentication) and CWE-306 (missing authentication for a critical function).

• Established: CISA assessed the flaw as actively exploited and placed it on the federal remediation list. NVD's SSVC record, attributed to a CISA Coordinator and timestamped 2 September 2026, records exploitation as "active", automatable as "yes" and technical impact as "partial".

• Established: exploitation was observed in a controlled environment. Wiz published honeypot traffic showing requests with single-character tokens probing a model-enumeration endpoint: a GET to /v1/models carrying "Authorization: Bearer x". The Hacker News, reporting the KEV batch on 3 September, described the same activity as Wiz observing "exploitation efforts involving CVE-2026-59822 against its honeypots to probe model enumeration endpoints."

• Established: the severity scores both exist and differ by framework. BerriAI's advisory rates the flaw CVSS 4.0 at 8.8, high, with confidentiality high, integrity low and availability none; NIST's own CVSS 3.1 assessment, which is primary in NVD, puts it at 8.2. The two numbers describe the same defect under different scoring systems and should not be compared as if one superseded the other.

• Not established: any named victim. Neither CISA's alert, nor BerriAI's advisory, nor Wiz's write-up, nor The Hacker News's coverage identifies an organisation whose MCP tools were reached through this flaw, or reports credentials or data taken from one. The public record of exploitation is honeypot telemetry and a federal determination, not a disclosed breach.

• Not established: that no ransomware group uses it. The KEV field reads "Unknown", which is a value CISA assigns, not a finding of absence either way.

The June precedent, and the remote-code-execution chain this is not

This is the second LiteLLM flaw to reach the KEV catalog in 2026, and the earlier one is easy to confuse with it. CVE-2026-42271, added on 8 June 2026 with a deadline of 22 June, is a command injection in LiteLLM's MCP server test endpoints: Wiz describes endpoints that let a user test an MCP server configuration before saving it, with the command field passed to subprocess execution without validation. Attackers submitted a fake stdio server configuration whose command downloaded and ran a cryptominer, and returned a valid-looking MCP handshake so the test appeared to succeed. CISA's entry for it lists CWE-78 and CWE-77 — command and argument injection, not authentication.

That flaw is the one that chains. Wiz says CVE-2026-42271 "can be chained with a Starlette host header validation bypass (CVE-2026-48710) to achieve fully unauthenticated RCE", and that external researchers have linked the Qilin ransomware group to active exploitation of that chain. CVE-2026-48710 was added to the KEV catalog in the same 2 September batch as the LiteLLM bypass, with the same 16 September deadline, and CISA's own catalog note for the Starlette flaw says it could be chained with CVE-2026-42271. The Qilin link belongs to that pairing. It is not a finding about CVE-2026-59822, and nothing in the sources reviewed connects the ransomware group to the authentication bypass.

One administrative detail separates the two LiteLLM entries: the June listing's required action cites BOD 22-01, the older binding operational directive, while the September listing cites BOD 26-04, "Prioritizing Security Updates Based on Risk". CISA's alert does not explain the change, and the catalog does not annotate it.

What changed after

The remediation path is short. BerriAI's advisory recommends upgrading to 1.84.0 or later, and offers a workaround for teams that cannot move immediately: "disable MCP routes or block access to /mcp/ and related MCP endpoints at your reverse proxy or API gateway." That workaround is a blunt instrument — it removes the capability rather than gating it — but it is the only mitigation the vendor names for unpatched deployments.

CISA's required-action text for the entry points federal agencies at the same trade-off: apply mitigations per vendor instructions and in line with BOD 26-04, "or discontinue use of the product if mitigations are unavailable", with responsibility on each agency to evaluate an asset's internet exposure. The directive is binding only on federal civilian executive branch agencies; CISA encourages other organisations to adopt the same risk-based prioritisation without requiring it.

Whether anyone outside a honeypot acted on the deadline is not public. Neither CISA nor BerriAI has published figures on how many LiteLLM deployments were exposed, how many were patched before 16 September, or how many were reached through the bypass.

What remains open

Three gaps are worth stating rather than papering over. There is no public incident report tying CVE-2026-59822 to a specific intrusion, so the KEV listing rests on CISA's exploitation evidence and Wiz's honeypot observations rather than on a documented victim. There is no vendor statement on how the fallback path came to be written that way, or how long it existed before 1.84.0 — the advisory describes the defect and its fix, not its history. And the batch's deadlines were not uniform: five of the seven entries added on 2 September carried a 5 September deadline, while the LiteLLM and Starlette entries carried 16 September. CISA does not say why.

What is settled is narrower and more useful than the score. A single character in an Authorization header was, on affected versions, indistinguishable from a valid key to the MCP endpoint — and the versions that behaved that way stopped being current in May 2026.