Submit #811282: litellm <= 1.59.8 Improper Authentication (CWE-287)

# Technical Details
An Authentication Bypass vulnerability exists in the `process_mcp_request` method in `litellm/proxy/_experimental/mcp_server/auth/user_api_key_auth_mcp.py` of litellm.

The application fails to properly fail closed when a user utilizes a bad or forged authentication token to access backends, resulting in 401 and 403 `HTTPException` exceptions being universally swallowed without action.

# Vulnerable Code
File: `litellm/proxy/_experimental/mcp_server/auth/user_api_key_auth_mcp.py`
Method: `process_mcp_request`
Why: The authentication logic intercepts `HTTPException` classes during token checks but simply passes rather than halting execution. It mistakenly instantiates a default `UserAPIKeyAuth()` response object. If an `allow_all_keys: true` MCP server exists behind the proxy, the request automatically proxies blindly as an authenticated interaction.

# Reproduction
1. Set up a LiteLLM Proxy hosting any MCP server equipped with the `allow_all_keys: true` boolean.
2. Send an incoming `POST` request to the proxy hitting the MCP endpoint specifying an entirely fake header (e.g., `Authorization: Bearer FAKE_TOKEN`).
3. The proxy will swallow the core credential failure, generating a `UserAPIKeyAuth()` entity, and route the API call to the target backend returning a success (`HTTP 200`).

# Impact
- Systemic Authentication Bypass exposing protected tools via the MCP mechanism.
- Possible Remote Code Execution (RCE) or Critical Data Exposure depending entirely upon the underlying MCP service configured behind the wall.

• Source: ⚠️ https://gist.github.com/YLChen-007/3cfaad10a69d7a15e4d4d458cb53309e
• User: Eric-c (UID 96848)
• Submission: 04/23/2026 09:57 (2 months ago)
• Moderation: 06/20/2026 11:26 (2 months later)
• Status: Accepted
• VulDB entry: 372515 [BerriAI litellm up to 1.59.8 MCP Proxy user_api_key_auth_mcp.py UserAPIKeyAuth improper authentication]
• Points: 20