CVE-2026-59822, BerriAI LiteLLM: a failed key check on the MCP gateway substitutes an empty auth object instead of rejecting the request, so a fabricated Bearer token opens a live MCP session

LiteLLM is a widely deployed proxy/gateway that lets an organisation front many LLM providers behind one API and, via the Model Context Protocol (MCP), let connected AI agents call external tools through it. Its MCP Streamable HTTP endpoint supports an OAuth2-passthrough mode for upstream MCP servers; the flaw sits in what happens when the gateway's own key check fails. Instead of rejecting the request, the fallback path replaces the failed validation with an empty UserAPIKeyAuth() object, which the rest of the request pipeline treats as a legitimately authenticated session (BerriAI, via OSV.dev). An attacker who sends any fabricated Authorization: Bearer value (no valid LiteLLM key required) therefore establishes a working MCP session and can list and invoke every MCP tool and connected service the gateway exposes (BerriAI, via OSV.dev). CISA's KEV addition on 2026-09-02 confirms this is under active exploitation, not merely disclosed (CISA Known Exploited Vulnerabilities catalog, 2026-09-02). Fixed in 1.84.0; where an immediate upgrade is not possible, BerriAI's own guidance is to block /mcp/ and related MCP endpoints at the reverse proxy or API gateway in front of LiteLLM (BerriAI, via OSV.dev).

This is a distinct code path from two other recently covered LiteLLM/MCP-surface flaws: CVE-2026-42271 was a command injection through MCP stdio test endpoints, chained with the Starlette host-header bypass CVE-2026-48710 in a real production intrusion Microsoft documented in August. CVE-2026-59822 hits the Streamable HTTP transport's OAuth2 fallback logic instead, a different mechanism on the same class of MCP-facing attack surface, not a re-run of the earlier bug.

Triage: an MCP session that never completed a valid key check but is nonetheless treated as authenticated is the tell; any environment logging MCP-gateway auth decisions should flag sessions where the presented Bearer token does not match an issued LiteLLM key yet the request pipeline proceeds past the auth stage.