Authentication Bypass Using an Alternate Path or Channel Affecting litellm package, versions [,1.84.0)

litellm is a Library to easily interface with LLM API providers

Affected versions of this package are vulnerable to Authentication Bypass Using an Alternate Path or Channel via the OAuth2 passthrough fallback in MCPRequestHandler.process_mcp_request in litellm/proxy/_experimental/mcp_server/auth/mcp_request_handler.py. An attacker can establish an authenticated MCP session without a valid LiteLLM key by sending a fabricated Authorization bearer token to an MCP route. When user_api_key_auth rejected the header with a 401 or 403, the handler replaced the failure with an anonymous UserAPIKeyAuth() object instead of denying the request. That lets the attacker reach MCP tooling and use connected upstream services exposed through MCP, breaking access control for deployed MCP endpoints.

Notes

• The bypass only applies on MCP transport routes that rely on the Authorization header for LiteLLM auth; requests with an explicit x-litellm-api-key follow the normal validation path instead of the OAuth2 passthrough fallback.
• Mixed-target MCP requests are affected as a group: if a request names multiple servers via x-mcp-servers, a single non-oauth2 target is enough to make the fallback unsafe and the auth failure propagates instead of being downgraded to anonymous passthrough.

Workarounds

• Disable MCP routes, or block access to /mcp/ and related MCP endpoints at your reverse proxy or API gateway, to prevent unauthenticated requests from reaching MCP tooling.

• GitHub Commit
• GitHub PR
• GitHub Release
• Maintainer's Advisory