CVE-2026-12773: LiteLLM: MCP Proxy Has Improper Authentication

The report describes process_mcp_request in the MCP proxy calling user_api_key_auth, which raises a 401 or 403 on a bad key. The code caught those errors and carried on with a default UserAPIKeyAuth() object, so the request proceeded as if it were authenticated. get_allowed_mcp_servers then returned every MCP server configured with allow_all_keys: true.

The fix commit shows the same area. Before it, any 401 or 403 became an anonymous session whatever the target server's auth_type. Public-route detection also matched .well-known anywhere in the URL, so an attacker could put the string in a query string or hostname to skip authentication.

The attacker needs network access to the proxy and an MCP server exposed with allow_all_keys: true. A fake Bearer token was enough in the researcher's proof of concept, which got a tools/list reply with HTTP 200. From there they can call the MCP tools behind the proxy. What that means depends on the tools: data access, or commands, if a server exposes them. The researcher claims this could lead to code execution. That claim is theirs, and the sources do not confirm it.

The pip package litellm before 1.84.0 per the advisory data. The NVD-style description and the researcher's report say up to 1.59.8, so the two ranges do not match, and 1.84.0 is the safe target. Exposure needs the MCP gateway in use and at least one MCP server with allow_all_keys: true.

pip show litellm

Check your proxy config for MCP servers and the allow_all_keys setting.

Upgrade litellm to 1.84.0.

pip install --upgrade litellm==1.84.0

The fix commit in the litellm repository does two things in MCPRequestHandler.process_mcp_request. It requires the public path to start with /.well-known/. It also applies the anonymous OAuth2 fallback only when every targeted MCP server uses oauth2; otherwise the auth error is returned. Targets come from the x-mcp-servers header, or from /mcp/{server_name} or /{server_name}/mcp, and unknown routes fail closed. The sources give no workaround. Until you upgrade, remove allow_all_keys: true from MCP servers and keep the proxy off untrusted networks.

Look in the proxy's access logs for MCP requests (/mcp routes, tools/list, tools/call) that carry an invalid or unknown Bearer token but return 200. Check for .well-known in query strings or hostnames on MCP URLs. Review the MCP servers behind the proxy for tool calls with no matching LiteLLM virtual key.

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.