LiteLLM MCP gateway accepted any fabricated Bearer token, exposing connected tools

BerriAI (LiteLLM)·LiteLLM proxy — MCP Streamable HTTP gatewayFixed

LiteLLM's MCP Streamable HTTP endpoint let an unauthenticated attacker send a fabricated Authorization header; when the real LiteLLM key check failed, an OAuth2 passthrough fallback silently substituted an empty, unrestricted UserAPIKeyAuth() object instead of rejecting the request, so the request reached MCP tooling anyway. Wiz's honeypots later recorded live exploitation using single-character Bearer tokens (e.g. 'Bearer x') to probe model-enumeration endpoints on exposed proxies.

Blast radius

Any internet-facing LiteLLM deployment on a version before 1.84.0 could have its configured MCP tools and connected services (databases, internal APIs, and other backends reachable through MCP) listed and called by an unauthenticated attacker; the flaw was assigned CVSS 8.8 (High), added to CISA's Known Exploited Vulnerabilities catalog, and Wiz Threat Research documented active scanning/exploitation attempts against real internet-facing instances. No single named victim organization or data-loss figure is disclosed in the sources.

Root cause

The MCP auth handler's OAuth2 passthrough fallback treated a failed LiteLLM API-key validation as a no-op by returning an empty, permission-less UserAPIKeyAuth() object instead of failing closed, so any Authorization header value satisfied the check (CWE-287 improper authentication, CWE-306 missing authentication for critical function).

How it was caught

Reported through GitHub coordinated disclosure by external researcher yaaras before public exploitation was confirmed; separately, Wiz Threat Research independently detected live exploitation attempts against the vulnerability in its own AI-infrastructure honeypots months after the CVE and patch were public, indicating unpatched instances remained exposed in the wild.

What changed

BerriAI patched the fallback logic in LiteLLM 1.84.0 so failed key validation is rejected rather than passed through; the advisory also recommends blocking or disabling /mcp/ routes at the reverse proxy/API gateway for anyone who cannot upgrade immediately.

Take-awayAuthentication fallback and error-handling branches must fail closed — never substitute an unrestricted or empty-but-valid auth object when a credential check errors or fails.