LiteLLM Flaw (CVE-2026-59822) Let Hackers Bypass Auth via Fake Bearer Tokens

A high-severity authentication bypass in LiteLLM, one of the most widely adopted open-source gateways for managing LLM API traffic, could have allowed unauthenticated attackers to hijack Model Context Protocol (MCP) sessions using nothing more than a made-up Bearer token.

Tracked as CVE-2026-59822 and disclosed via GHSA-7488-6r32-c95q, the flaw exposes a critical gap in how LiteLLM handled OAuth2 passthrough authentication for upstream MCP servers.

LiteLLM’s MCP Streamable HTTP endpoint was designed to support OAuth2 passthrough, allowing requests to carry credentials intended for upstream MCP servers rather than LiteLLM itself.

LiteLLM Flaw

The problem surfaced in the fallback logic: when LiteLLM’s own key validation failed, the auth handler instead silently substituted an empty UserAPIKeyAuth() object.

That empty object effectively told the system “this request is fine, just without specific permissions attached,” rather than treating the failed validation as a hard stop.

An attacker could send a completely fabricated Authorization header and still get waved through to MCP tooling, no valid LiteLLM key required.

The vulnerability’s CVSS 4.0 score reflects a genuinely dangerous combination: a network-based attack vector, low complexity, no privileges required, and no user interaction required.

The confidentiality impact on vulnerable systems is rated High, meaning an attacker exploiting this could:

List all MCP tools configured on the affected LiteLLM instance
Invoke those tools directly, without authorization
Access any backend services or data sources connected through MCP integrations

For organizations using LiteLLM as a gateway to orchestrate AI agent workflows, this means the very connective tissue linking LLMs to internal systems, databases, and third-party services could be exposed to anyone who simply knew where to send a crafted request.

Security researcher yaaras is credited with identifying the flaw, while GitHub user jaydns published the advisory on July 2, 2026.

LiteLLM’s maintainers responded by patching the fallback logic in version 1.84.0, released shortly after disclosure. The fix ensures that failed key validation results in outright rejection rather than a permissive empty-auth fallback.

Mitigation

Anyone running LiteLLM versions prior to 1.84.0 with MCP endpoints enabled should treat this as urgent:

Upgrade to LiteLLM 1.84.0 or later immediately
If an immediate upgrade isn’t feasible, disable MCP routes entirely or block access to /mcp/ and related endpoints at the reverse proxy or API gateway level
Audit logs for unusual MCP tool invocations or Bearer tokens that don’t correspond to issued LiteLLM keys, particularly since the initial disclosure

This disclosure lands amid a broader wave of scrutiny around MCP implementations, as the protocol has rapidly become a standard bridge between AI agents and enterprise tooling.

Authentication fallback logic, in particular, is proving to be a recurring weak point: when a system fails “safe” by silently downgrading permissions instead of denying access outright, it inverts the entire security model.

Expect more MCP-adjacent CVEs as adoption accelerates and researchers dig deeper into how these gateways handle edge cases.