CVE-2026-59822: What an MCP Authentication Bypass in LiteLLM Teaches About Session-Level Authorization

On September 2, 2026, CISA added seven vulnerabilities to its Known Exploited Vulnerabilities catalog, and one of them sits inside an AI gateway most enterprise LLM deployments already run. CVE-2026-59822 affects LiteLLM's Model Context Protocol (MCP) Streamable HTTP endpoint in every version before 1.84.0. When LiteLLM's own key validation failed on an MCP request, the code fell back to an OAuth2 passthrough path that substituted an empty UserAPIKeyAuth() object instead of rejecting the call, so a fabricated Bearer token in the Authorization header reached MCP tooling as if it had passed authentication. BerriAI's own advisory, GHSA-7488-6r32-c95q, rates it CVSS 8.8. CISA's KEV addition confirms this is being exploited now, not a theoretical finding sitting in a scan report.

TL;DR

• CVE-2026-59822 lets an unauthenticated caller reach LiteLLM's MCP tooling by sending a fabricated Bearer token that triggers a broken OAuth2 fallback path.
• The fallback substituted an empty authorization object for a rejected credential instead of denying the request, a fail-open pattern in code meant to fail closed.
• CISA's September 2, 2026 KEV addition confirms active exploitation, and every version of LiteLLM before 1.84.0 is affected.
• This is a distinct failure from CVE-2026-12773 (LiteLLM's earlier UserAPIKeyAuth bypass): that one hit the general proxy API, this one hits the MCP tool-call boundary specifically.

The fallback path that failed open

MCP gives an LLM application a standard way to call external tools: file systems, databases, ticketing systems, whatever a server exposes. LiteLLM's Streamable HTTP transport for MCP was built to support two authentication modes at once. A caller could present a valid LiteLLM credential, or the gateway could pass an OAuth2 token straight through to an upstream MCP server that manages its own authorization. The passthrough mode exists because plenty of MCP servers already run their own OAuth2 flow, and LiteLLM didn't want to force a second authentication layer on top of it.

The defect is in what happened when the LiteLLM-side authentication check failed. Instead of stopping the request, the code constructed an empty UserAPIKeyAuth() object and let the request continue toward the MCP server under that empty identity. An attacker who sent any Bearer token, valid or not, watched the failed check quietly downgrade into an authorized-looking request. From there, the advisory describes the attacker listing every MCP tool the gateway had configured and calling the ones that responded.

Why an MCP-boundary bypass is a different problem than a proxy-API bypass

LiteLLM shipped two other CVEs earlier in 2026: CVE-2026-42271, a remote code execution flaw in the proxy's admin config handler, and CVE-2026-12773, an authentication bypass in the UserAPIKeyAuth path that exposed the /key/generate and /key/info endpoints. I walked through what that CVE wave meant for gateway control-plane design in June. Both of those bugs targeted the gateway's own authentication surface, the part of LiteLLM that mints and inspects credentials.

CVE-2026-59822 targets something adjacent but architecturally different: the boundary between the gateway and every tool an MCP server exposes to a model. A compromised credential endpoint lets an attacker mint credentials. A compromised MCP authentication path lets an attacker skip credentials entirely and act as a tool-calling agent. The blast radius runs through whatever the connected MCP servers can do: read a file system, query a production database, or open a ticket under someone else's name. The fix in 1.84.0 is a patch to one fallback branch. The pattern it exposes is broader.

What CISA's KEV addition actually confirms

CISA doesn't add a CVE to the Known Exploited Vulnerabilities catalog on the strength of a CVSS score alone. The catalog exists for vulnerabilities under active exploitation, and federal civilian agencies now have a remediation deadline of September 16, 2026 to patch or mitigate this specific bug. That two-week window is short by patch-management standards, and it reflects how directly exploitable the flaw is: a single crafted HTTP header, no privilege escalation chain required.

I think the more interesting number here isn't the CVSS score, it's how little exploitation actually required. Sending a fabricated Bearer token is not a sophisticated attack technique. It is the kind of request a vulnerability scanner sends by accident. A gateway that fails open on a malformed credential is exposed to exactly that level of adversary, which is most of the internet.

The compensating control the fallback path needed

The architectural lesson isn't "patch faster," though patching to 1.84.0 is the immediate fix. It's that authentication and authorization decisions at an MCP session boundary need to fail closed independent of what the fallback logic inside the gateway does. A policy layer that evaluates every MCP tool call against a verified identity, separate from the gateway's own internal key check, would have rejected the fabricated-token request regardless of what the OAuth2 passthrough branch did internally. Relying on a single code path inside the gateway to be the only thing standing between an MCP tool and an unauthenticated caller is the actual failure mode, not just the specific UserAPIKeyAuth() bug.

DeepInspect

This is exactly what DeepInspect does. DeepInspect sits inline as a stateless proxy between authenticated users or agents and any HTTP-based LLM endpoint, MCP tool calls included, and evaluates every request against identity, role, and policy before it reaches the model or the tool it's calling. A fabricated Bearer token doesn't get a second chance through an internal fallback branch, because the policy decision happens outside the gateway code that CVE-2026-59822 lives in.

The resulting record for every MCP tool call is a signed, per-decision audit entry: who authorized this call, under which policy, at what moment, with what outcome. That record exists independent of whether the upstream gateway's own authentication logic behaved correctly on any given request, which is the property CVE-2026-59822 shows most gateways don't have today. Book a demo today.