CISA Adds LiteLLM MCP Authentication Bypass to Known Exploited Vulnerabilities Catalog After Failed Keys Were Downgraded to Valid Sessions

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) added LiteLLM vulnerability CVE-2026-59822 to its Known Exploited Vulnerabilities (KEV) catalog on September 2, marking a significant update to the flaw first disclosed in June. The issue lies in authentication handling for the MCP Streamable HTTP endpoint. LiteLLM supports OAuth2 passthrough for upstream MCP servers, but after LiteLLM API key validation failed, a specific fallback path did not reject the request outright. Instead, processing continued with an empty `UserAPIKeyAuth()` object. An attacker could therefore submit any Bearer token and potentially have it treated as an authenticated session.

The impact extends beyond obtaining chat or model responses. According to the maintainers’ security advisory, a successful attacker could list and invoke MCP tools configured in LiteLLM, potentially gaining access to the databases, cloud services, or other enterprise systems behind those tools. The vulnerability can be exploited remotely over a network without existing privileges or user interaction. GitHub’s advisory assigns it a CVSS 4.0 score of 8.8, driven primarily by a high confidentiality impact and a lower integrity impact.

LiteLLM versions earlier than 1.84.0 are affected; the fix is available in version 1.84.0 and later. If an immediate upgrade is not possible, the maintainers recommend disabling MCP routes or blocking `/mcp/` and related endpoints at the reverse proxy or API gateway. CISA set a September 16 remediation deadline for U.S. Federal Civilian Executive Branch agencies. Inclusion in the KEV catalog indicates evidence of exploitation, but it does not mean every deployment has been compromised. The Hacker News, citing Wiz honeypot observations, reported that probes attempting model enumeration through this vulnerability have already been observed.

Operators should not limit their response to checking package versions. They should first inventory which LiteLLM instances are reachable from the internet or untrusted network segments and identify which MCP tools have write capabilities. They should then inspect logs for anomalous Bearer tokens, tool enumeration, and tool invocations. If an endpoint was exposed, operators should also rotate any upstream API keys accessible to MCP tools and verify that the gateway fails closed across all authentication exceptions and passthrough branches. An external login page or an “internal service” label alone is not enough to define the actual attack surface.