~/news/2026-09-21-litellm-mcp-auth-bypass.md

What happened. LiteLLM, the proxy a lot of teams put in front of their model APIs, had an MCP endpoint that accepted any bearer token at all. CISA added CVE-2026-59822 to the Known Exploited Vulnerabilities catalog on 2026-09-02, and membership there is evidence of active exploitation rather than a prediction.

Why it matters. An AI gateway is a key store that answers HTTP. Whatever sits behind it is reached with the credentials it holds, so an authentication flaw here is not one exposed service, it is every upstream provider credential that service was trusted with. This is the class worth watching hardest right now: the agent tooling layer is young, it is exposed to the internet by design, and it is where the secrets live.

Mechanism. The MCP Streamable HTTP endpoint took a LiteLLM key in the Authorization header. It also carried an OAuth2 passthrough path for upstream MCP servers, and when key validation failed, that fallback substituted an empty UserAPIKeyAuth() object instead of rejecting the request. Downstream code received a success where a refusal belonged, so a fabricated bearer token could list and call configured MCP tools and reach everything connected through them. The bug is not a missing check. It is a failed check that got treated as a satisfied one, and that shape is worth recognising anywhere you find it.

What to do. Upgrade to 1.84.0 or later. Then treat the credentials as exposed rather than merely at risk and rotate them: the LiteLLM master key, the virtual keys, and every upstream provider key the instance held. The flaw lets a stranger read them, so patch alone is the smaller half of the response. If MCP routes are not needed on an internet facing instance, turn them off, and do not count on the gateway being hard to find as a control.