LiteLLM CVE-2026-59822: Failed Auth Fell Through to an Empty MCP Session

By George Bailey   Published: 09/09/26   Updated: 09/09/26   2 min read

What Changed

BerriAI’s LiteLLM AI gateway—widely used to proxy OpenAI-compatible and multi-provider LLM traffic—contained an improper authentication flaw in its Model Context Protocol (MCP) Streamable HTTP path. In versions before 1.84.0, a failed LiteLLM API-key check on an Authorization: Bearer … header could fall through an OAuth2-passthrough branch that substituted an empty UserAPIKeyAuth() object instead of failing closed.

The result: an unauthenticated caller with an arbitrary Bearer token could establish an authenticated MCP session and reach configured MCP tooling. CISA added CVE-2026-59822 to KEV on September 2, with a federal remediation deadline of September 16. The 1.84.0 fix gates passthrough on actual target-server OAuth2 configuration and fails closed when servers cannot be resolved or are not in OAuth2 mode.

Why This Matters Operationally

LiteLLM often sits in front of production model keys, tool connectors, and internal MCP servers that can read tickets, query databases, or trigger automations. An empty auth object is not a “read-only preview”—it is a session that subsequent authorization checks treat as validated. AI gateways are becoming the SSO for tool-using agents; failing open on the MCP path turns “any Bearer string” into “call my tools.”

What Defenders Should Verify First

Source Context

Upgrade past 1.84.0, lock down /mcp, and assume any exposed gateway minted sessions you did not intend.

George Bailey

George Bailey is a cybersecurity researcher and writer at CyberExperts, covering cyber threats, AI, cloud security, vulnerabilities, and defensive strategies. His goal is to help security professionals quickly understand what matters most and how it impacts their organizations.