BerriAI litellm MCP Proxy user_api_key_auth_mcp.py UserAPIKeyAuth improper authentication
Description
A weakness has been identified in BerriAI litellm up to 1.59.8. Affected is the function UserAPIKeyAuth of the file litellm/proxy/_experimental/mcp_server/auth/user_api_key_auth_mcp.py of the component MCP Proxy. Executing a manipulation can lead to improper authentication. The attack may be launched remotely. The exploit has been made available to the public and could be used for attacks. The vendor was contacted early about this disclosure.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
Affected products
1Patches
Vulnerability mechanics
Root cause
"The `process_mcp_request` function catches 401/403 HTTPExceptions from API key validation and silently swallows them, instantiating a default `UserAPIKeyAuth()` object instead of rejecting the request."
Attack vector
An unauthenticated remote attacker sends a JSON-RPC request to an MCP endpoint (e.g., `/mock_server/mcp`) with an arbitrary invalid `Authorization: Bearer` token. The `process_mcp_request` function catches the 401/403 `HTTPException` from the API key validation and swallows it, creating a default `UserAPIKeyAuth()` object. This bypasses authentication entirely, and if the target MCP server has `allow_all_keys: true`, the attacker gains full access to backend MCP tools [ref_id=1]. The attack is trivially exploitable with a single `curl` command [CWE-287, CWE-390].
Affected code
The vulnerability resides in `litellm/proxy/_experimental/mcp_server/auth/user_api_key_auth_mcp.py`, specifically in the `process_mcp_request` function. This function catches `HTTPException` (401/403) raised by `user_api_key_auth` and silently swallows the exception, returning a default `UserAPIKeyAuth()` object instead of rejecting the request [ref_id=1].
What the fix does
The advisory does not include a published patch. The recommended fix is to stop swallowing 401/403 `HTTPException` in `process_mcp_request` and instead propagate the exception so that unauthenticated requests are properly rejected. Additionally, the authorization flow in `get_allowed_mcp_servers` should not grant access when authentication has failed, even if `allow_all_keys` is enabled [ref_id=1].
Preconditions
- configThe LiteLLM proxy must be configured with at least one MCP server that has `allow_all_keys: true`
- networkThe attacker must be able to send HTTP requests to the MCP endpoint (network reachability)
- inputNo valid API key is required; any arbitrary token in the Authorization header suffices
Reproduction
```bash curl -i -X POST http://localhost:4000/mock_server/mcp \ -H "Authorization: Bearer ANY_FAKE_TOKEN_TO_BYPASS_AUTH" \ -H "Content-Type: application/json" \ -d '{"jsonrpc": "2.0", "id": 1, "method": "tools/list", "params": {}}' ``` The server responds with `200 OK` and lists protected tools, confirming authentication bypass [ref_id=1].
Generated on Jun 21, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
5- gist.github.com/YLChen-007/3cfaad10a69d7a15e4d4d458cb53309emitreexploit
- vuldb.com/cve/CVE-2026-12773mitrethird-party-advisory
- vuldb.com/submit/811282mitrethird-party-advisory
- vuldb.com/vuln/372515mitrevdb-entrytechnical-description
- vuldb.com/vuln/372515/ctimitresignaturepermissions-required
News mentions
0No linked articles in our index yet.