Published:
MCP endpoint of AI gateway LiteLLM lands on CISA's actively exploited list
In short: on 2 September 2026 the US cyber agency CISA added CVE-2026-59822 to its catalog of actively exploited vulnerabilities. The MCP endpoint of AI gateway LiteLLM accepted a fabricated Authorization header, granting access to the MCP tooling behind it. The flaw is fixed in version 1.84.0.
The bug itself is unremarkable. What makes it notable is the recognition: in CISA's KEV catalog — the list of vulnerabilities with proven exploitation in the wild — this is the only entry that explicitly names an MCP endpoint as the attack path (catalog version 2026.09.21). The AI gateway, that unglamorous piece of infrastructure through which many organisations route all model traffic and every MCP connection, is now officially a target.
What exactly went wrong?
LiteLLM is a widely used open-source proxy that hides model calls to different providers behind a single OpenAI-compatible API, and that can also expose MCP servers. In versions before 1.84.0, its MCP Streamable HTTP endpoint contained a flaw: when OAuth2 passthrough authentication to an upstream MCP server failed, the code fell back to an empty UserAPIKeyAuth() object instead of rejecting the request. An attacker who simply sent along a fabricated bearer token obtained a valid MCP session without ever holding a real LiteLLM key.
The numbers: CVSS 8.8 (v4.0; 8.2 under v3.1), classified as CWE-287 and CWE-306 — improper authentication and missing authentication for a critical function. The vendor advisory appeared on 30 June 2026 and the NVD record on 8 July. Only two months later, on 2 September, came the KEV listing, with a 16 September remediation deadline for US federal agencies. In other words: the fix was available well before the exploitation started.
That exploitation is not an assumption. Researchers at Wiz reported on 9 September that they observed this flaw being exploited against their honeypots, with requests using the bypassed endpoint to enumerate available models. The same write-up describes the follow-on step that determines the impact: once past the gateway, you get to talk to the MCP servers behind it. If a database query tool is connected, the attacker runs queries; if a GitHub integration is connected, they read repositories.
Why does this matter even if you do not run LiteLLM?
Because the pattern is broader than the product. An AI gateway is, in practice, a credential store: it holds the API keys of your model providers, it knows the tokens to your MCP servers, and it faces the internet because your agents need to reach it from several places. A single authentication flaw in that layer therefore weighs more heavily than the same flaw in a stand-alone application.
The exposure is real, too. In February 2026 Wiz scanned 3,074 publicly reachable LiteLLM proxies: 294 of them (9.6%) accepted a default master key or required no authentication at all, of which 191 (6.2%) had no authentication whatsoever. A repeat scan in August 2026 found more than 85,000 instances, although the majority appear to be honeypots and test deployments — an indication of how much attention this category now attracts.
And the keys are the objective, not a by-product. In its threat intelligence report of 10 September 2026, Anthropic describes how multiple actors compromised the LiteLLM implementation of AI service providers and used prompt injection to exfiltrate the production API keys from their cloud environments. Stolen AI credentials give an attacker three things at once: resale value, free compute, and a bill that lands with the victim.
Our advice
Treat your AI gateway as production infrastructure with key management attached, not as a convenience owned by the AI team. Concretely, in this order: (1) inventory which MCP endpoints are genuinely reachable from the internet — usually more than you think; (2) check versions and default credentials, because a default master key makes any protocol debate irrelevant; (3) give the gateway minimal rights in your cloud environment and restrict outbound traffic, so a breach does not automatically reach your IAM roles; and (4) use the KEV catalog as a free prioritisation signal in your patch process, even without a US mandate. More background in our guides on MCP security & watchouts and trusted MCP sources.
The bigger picture
The MCP protocol itself is not on trial here — this is an implementation flaw in one product, and the recent specification revision actually hardens authorization. But the case does mark a transition. Over the past year, MCP security was mostly about malicious servers and poisoned tool descriptions: risks you mitigate through careful selection. This flaw sat in a server that organisations had installed themselves, deliberately and trustingly. The same discipline you apply to your API gateways — version management, key rotation, least privilege, an exposure inventory — now applies to the layer your agents speak through as well.
Sources
- CISA Known Exploited Vulnerabilities Catalog — entry for CVE-2026-59822 (added 2 September 2026)
- GHSA-7488-6r32-c95q — MCP Authentication Bypass via OAuth2 Passthrough Fallback (BerriAI/LiteLLM)
- CVE-2026-59822 — National Vulnerability Database
- Breaking LiteLLM: From Authentication Bypass to Cloud Compromise — Wiz (9 September 2026)
- Countering misuse of AI: September 2026 — Anthropic threat intelligence report
- CISA Adds Seven Exploited Flaws — The Hacker News (3 September 2026)
Frequently asked questions
Am I affected if I run LiteLLM?
Only versions before 1.84.0 are vulnerable to CVE-2026-59822. Check your version and upgrade; if you cannot upgrade immediately, the vendor advises blocking /mcp/ and related MCP endpoints at your reverse proxy or API gateway.
Does this flaw affect my MCP servers themselves?
The bug is in LiteLLM, not in the MCP protocol. But anyone who gets past the gateway does reach the MCP servers behind it — a database query tool or a GitHub connection will simply do its job for the attacker.
Is the CISA KEV catalog relevant outside the US?
The patching mandate only binds US federal agencies, but the catalog is public and free. As a prioritisation signal it works for everyone: a KEV listing means there is evidence of exploitation in the wild, not just a theoretical risk.
Last updated: