CVE-2026-59822: 
Chainguard Análisis y mitigación de vulnerabilidades

CVE-2026-59822 is an authentication bypass vulnerability in LiteLLM (an AI Gateway/proxy server) affecting the MCP (Model Context Protocol) Streamable HTTP endpoint. An unauthenticated attacker can supply a fabricated Authorization header to trigger an OAuth2 passthrough fallback path that replaces failed LiteLLM key validation with an empty UserAPIKeyAuth() object, granting access to MCP tooling without a valid LiteLLM key. All versions prior to 1.84.0 are affected. The vulnerability was disclosed on June 30, 2026, and carries a CVSS v4.0 base score of 8.8 (High) (GitHub Advisory, Feedly).

The root cause is improper authentication (CWE-287) and missing authentication for a critical function (CWE-306) in MCPRequestHandler.process_mcp_request within litellm/proxy/_experimental/mcp_server/auth/user_api_key_auth_mcp.py. Two distinct bypass paths existed: (1) the public-route guard used ".well-known" in str(request.url) — a substring match against the full URL — allowing attackers to smuggle the marker via query string (e.g., ?/.well-known) to bypass authentication on any MCP route; (2) the OAuth2 passthrough fallback, originally added to support auth_type=oauth2 upstream MCP servers, caught any 401/403 from user_api_key_auth and unconditionally replaced the result with an anonymous UserAPIKeyAuth(), regardless of the target server's configured auth_type. This meant any request with a garbage Authorization header that failed LiteLLM key validation would be silently granted an anonymous session. No privileges or user interaction are required; the attack is network-accessible with low complexity (GitHub Advisory, Fix PR).

Successful exploitation allows an unauthenticated attacker to establish an authenticated MCP session using any arbitrary Bearer token, effectively bypassing all LiteLLM key-based access controls on the MCP endpoint. The attacker can enumerate and invoke all configured MCP tools and access any connected services exposed through MCP — which may include internal APIs, data stores, or third-party integrations. The primary impact is high confidentiality loss (access to sensitive data and tool outputs) and low integrity impact (ability to invoke tools that may modify data or trigger actions), with no direct availability impact (GitHub Advisory).

1. Reconnaissance: Identify internet-facing or network-accessible LiteLLM proxy instances running versions prior to 1.84.0 with MCP endpoints enabled (e.g., /mcp/ routes). Tools like Shodan or Censys can be used to locate exposed instances.
2. Craft a fabricated Authorization header: Prepare an HTTP request with any arbitrary Bearer token in the Authorization header (e.g., Authorization: Bearer garbage_token_value). No valid LiteLLM API key is needed.
3. Target the MCP Streamable HTTP endpoint: Send the crafted request to the MCP endpoint (e.g., POST /mcp/{server_name} or /{server_name}/mcp). The handler attempts LiteLLM key validation, which fails with a 401/403.
4. Trigger the OAuth2 fallback: The failed validation triggers the OAuth2 passthrough fallback path, which replaces the auth result with an empty UserAPIKeyAuth() object, granting an anonymous authenticated session.
5. Access MCP tooling: With the anonymous session established, enumerate available MCP tools (e.g., via tools/list) and invoke them (e.g., via tools/call) to access connected services, exfiltrate data, or trigger actions on integrated backends (GitHub Advisory, Fix PR).

• Network: Unexpected HTTP requests to /mcp/, /{server_name}/mcp, or /mcp/{server_name} endpoints from unknown or external IP addresses; requests containing Authorization: Bearer <arbitrary_value> headers that do not correspond to valid LiteLLM API keys.
• Logs: LiteLLM proxy logs showing debug messages such as "MCP OAuth2: Authorization header is not a valid LiteLLM key, treating as OAuth2 token passthrough" for requests from unexpected sources; repeated 401/403 auth failures on MCP routes immediately followed by successful tool invocations from the same source IP.
• Application Behavior: Unexpected MCP tool calls (e.g., tools/list or tools/call) appearing in audit or access logs without corresponding valid API key entries; unusual data access patterns on services connected via MCP tools (Fix PR, GitHub Advisory).

Upgrade LiteLLM to version 1.84.0 or later, which fixes both the public-route detection bypass and the OAuth2 fallback fail-open behavior. The fix tightens the public-route check to use request.url.path.startswith("/.well-known/") and gates the OAuth2 fallback through a new _target_servers_use_oauth2 helper that only allows anonymous passthrough when every targeted MCP server is explicitly operator-configured with auth_type=oauth2. If immediate upgrade is not possible, disable MCP routes or block access to /mcp/ and all related MCP endpoints at your reverse proxy or API gateway (GitHub Advisory, v1.84.0 Release).

The vulnerability was reported by security researcher yaaras and the advisory was published by jaydns on the BerriAI/litellm GitHub repository. The fix was implemented by contributor stuxf and received a 5/5 confidence score from the Greptile automated review bot, which noted both security fixes were correctly implemented and thoroughly tested. The NixOS security tracker also opened a tracking issue (NixOS/nixpkgs#539896) to address the vulnerability in the nixpkgs ecosystem (GitHub Advisory, Fix PR).