LiteLLM MCP Endpoint Authentication Bypass via OAuth2 Passthrough Fallback

Technical Analysis

The flaw resides in how LiteLLM's MCP Streamable HTTP endpoint handles Authorization headers: when a malformed or fabricated OAuth2-style header is presented, LiteLLM's key-validation logic fails but instead of rejecting the request, it falls back to constructing an empty UserAPIKeyAuth() object, granting a default (unauthenticated) identity access to MCP tool-calling functionality. The entry point is the network-facing MCP endpoint itself, requiring no valid credentials and no prior access. An attacker exploiting this gains the ability to invoke any MCP tools exposed through the gateway as if authenticated, potentially reaching backend LLMs, connected tool servers, or sensitive data sources gated behind the proxy. This crosses a critical trust boundary because LiteLLM acts as an authentication chokepoint between external callers and internal MCP tool servers/agents, so bypassing it effectively grants unauthorized lateral access into the entire downstream agentic tool ecosystem.

Affected Systems

LiteLLM; protocols: MCP

Detection Signatures

• Requests to MCP Streamable HTTP endpoints with malformed, non-standard, or fabricated Authorization/Bearer headers
• Log entries showing successful MCP tool invocation correlated with empty or null UserAPIKeyAuth / user_api_key fields
• Unexpected spikes in unauthenticated or anonymous MCP tool calls
• Authorization headers containing OAuth2 tokens that fail standard validation yet still proceed to tool execution
• Absence of corresponding API key in audit logs for successful MCP requests

Remediation Steps

1. 1

   Upgrade LiteLLM

   Update LiteLLM to version 1.84.0 or later, which fixes the OAuth2 passthrough fallback authentication bypass.

2. 2

   Audit MCP access logs

   Review historical logs for MCP endpoint requests with anomalous or malformed Authorization headers and unauthenticated tool invocations to identify potential prior exploitation.

3. 3

   Enforce strict auth failure handling

   Ensure any custom or forked deployments explicitly reject requests on key-validation failure rather than defaulting to an empty/anonymous auth object.

4. 4

   Restrict MCP endpoint exposure

   Limit network exposure of MCP Streamable HTTP endpoints to trusted networks or add an additional authentication layer (e.g., mTLS, network ACLs) as defense in depth.

5. 5

   Monitor tool-call authorization context

   Add alerting for MCP tool invocations lacking a valid, non-empty user API key association.