CISA adds LiteLLM MCP auth bypass CVE-2026-59822 to KEV

CISA added LiteLLM's CVE-2026-59822 to its Known Exploited Vulnerabilities catalog on September 2, which means the authentication bypass is confirmed exploited in the wild, not just disclosed. LiteLLM is the open-source proxy many teams run in front of self-hosted and open-weight models. The fix is v1.84.0, and the federal patch deadline has already passed.

Key facts

• CISA added CVE-2026-59822 to the KEV catalog on September 2, 2026, with a federal mitigation deadline of September 16 and an advisory noting attackers can "establish an authenticated MCP session using an arbitrary Bearer token."
• The flaw affects LiteLLM versions before v1.84.0 and is fixed in v1.84.0 via GitHub PR #26463.
• The vulnerability carries a CVSS score of 8.8 and is listed under CWE-287 (improper authentication) and CWE-306 (missing authentication for critical function) in CISA's feed.
• It is LiteLLM's third KEV entry of 2026, after CVE-2026-42271 (command injection, added June 8) and CVE-2026-42208 (SQL injection, added May 8), both also carrying federal patch deadlines that have now lapsed.
• Three of the seven vulnerabilities CISA added that day target AI infrastructure, which AI Weekly notes is the first KEV batch where AI components make up nearly half the additions.

What happened

The flaw lives in LiteLLM's Model Context Protocol (MCP) Streamable HTTP endpoint. That endpoint is supposed to authenticate callers with a LiteLLM-issued API key. According to SentinelOne's analysis, when key validation fails, the code falls into an OAuth2 passthrough branch meant to accept upstream provider tokens. That branch does not verify the token. It substitutes an empty UserAPIKeyAuth() object into the request context, and the rest of the pipeline treats the empty object as a successful login. An attacker sends one HTTP request with a made-up Authorization: Bearer header and lands inside whatever MCP tooling the proxy has configured.

BerriAI's fix in v1.84.0 makes the passthrough branch validate the token instead of assuming it. That is the whole patch, which is why version checks are so simple here: pip install --upgrade "litellm>=1.84.0".

The KEV listing is the part that changes the risk calculus. CISA does not add vulnerabilities to the catalog on speculation. Inclusion means CISA judged exploitation confirmed, and its alert required federal agencies to verify they were not compromised under BOD 26-04, not merely patch. That deadline was September 16 for this CVE.

Reporting on the batch also connected it to a broader campaign. AI Weekly's alert, citing The Hacker News, describes attackers chaining a Starlette request-smuggling flaw with LiteLLM's June command-injection bug (CVE-2026-42271) to drop XMRig miners and harvest the LiteLLM_ProxyModelTable and LiteLLM_VerificationToken tables, which hold model configuration, upstream provider keys, and proxy-issued virtual keys. Microsoft and Wiz telemetry reportedly shows LiteLLM, Flowise, LangChain, Ollama, and MCP servers treated as high-value targets for credential theft and persistence. Those specifics come from vendor telemetry reporting, not from our own verification, but the KEV listing itself is CISA's own record.

Why it matters

The pattern here is not exotic. LiteLLM is popular precisely because it solves a real problem: one OpenAI-shaped endpoint in front of many providers, including self-hosted open-weight models. That puts the proxy on the trust boundary between the internet and everything valuable behind it: provider credentials, tool access, and the data those tools can reach. When the boundary fails, it fails open.

This is the same lesson as the 152,137 exposed Ollama endpoints found in an internet-wide scan. The model runtime is rarely the weak point. The weak point is the convenience layer teams bolt on around it without treating it as a production security boundary. If you run LiteLLM with MCP tooling attached, the checklist from SentinelOne is concrete: upgrade to at least v1.84.0, rotate LiteLLM keys and any downstream provider credentials, review MCP invocation logs for tool calls with no attributable key, and restrict network access to the endpoint until you are patched.

One process note in the interest of how DeAI handles security stories: incidents like this get no automated verification grade from us. Our tracker verification gap analysis explains why: without a reproducible check, a claim about exploitation is a claim, and CISA's catalog listing is the disclosure of record, so that is what we cite.

Background

LiteLLM (by BerriAI) is one of the most widely deployed open-source LLM gateways, and MCP adoption has grown fast because agents increasingly need tool access through the same proxy that serves model traffic. That combination — agent tooling plus a credentials vault plus internet exposure — is what makes the proxy a target worth scanning for.

The KEV catalog is the closest thing security has to a fact-checker for "is this actually exploited?" It exists because vendors disclose vulnerabilities that never see real attacks, and defenders triage accordingly. A KEV listing moves a flaw to the top of every federal patch queue and usually signals that criminal operators got there first. For self-hosters, it is a reasonable proxy for urgency.

This is also the second time this year the self-hosting stack's plumbing made federal news. The May SQL injection and June command injection entries showed LiteLLM's database and host could be reached through the proxy itself. The September entry shows the authentication layer can fail open. Different bugs, same lesson: whatever runs your inference also holds your keys, and it needs patch discipline like any other production service.

What's next

The practical dates are behind us: the federal deadline was September 16, so any LiteLLM deployment older than v1.84.0 should be treated as overdue, not upcoming. What to watch now: whether CISA's next KEV batches continue the shift toward AI infrastructure (this was the first batch where AI components made up nearly half the additions), whether BerriAI publishes exploitation guidance beyond the advisory, and whether the Microsoft/Wiz telemetry on AI-stack compromises hardens into repeatable detection guidance. If you operate LiteLLM, the decision point is now: version check, key rotation, and an audit of every MCP tool the proxy can reach.