CVE-2026-59822: 
NixOS vulnerability analysis and mitigation

CVE-2026-59822 is an authentication bypass vulnerability in LiteLLM (BerriAI), an AI Gateway/proxy server for calling LLM APIs. The flaw exists in LiteLLM's MCP (Model Context Protocol) Streamable HTTP endpoint, where a fabricated Authorization header could trigger an OAuth2 passthrough fallback path that replaced failed LiteLLM key validation with an empty UserAPIKeyAuth() object, granting unauthenticated access to MCP tooling. All versions prior to 1.84.0 are affected. The vulnerability was published on June 30, 2026, and assigned a CVSS v3.1 score of 8.2 (High) and a CVSS v4.0 score of 8.8 (High) (Github Advisory, GHSA Advisory).

The root cause is classified as CWE-287 (Improper Authentication) and CWE-306 (Missing Authentication for Critical Function). The MCPRequestHandler.process_mcp_request function contained two related bypass paths: (1) the public-route guard used ".well-known" in str(request.url), a substring match against the full URL including query string, allowing attackers to smuggle the marker via query parameters (e.g., ?/.well-known) to bypass authentication on any MCP route; and (2) the OAuth2 passthrough fallback caught any 401/403 from user_api_key_auth and replaced the result with an anonymous UserAPIKeyAuth() object regardless of the target server's configured auth_type, meaning any garbage Authorization Bearer token could exchange a failed LiteLLM auth for an anonymous session. The fix in PR #26463 replaced the substring check with request.url.path.startswith("/.well-known/") and gated the OAuth2 fallback through a new _target_servers_use_oauth2 helper that only allows the fallback when every targeted MCP server is operator-configured for auth_type=oauth2 (GitHub PR, GitHub Commit).

Successful exploitation allows an unauthenticated remote attacker to establish an authenticated MCP session without a valid LiteLLM API key, gaining the ability to enumerate and invoke all configured MCP tools and access any connected services exposed through MCP. The primary impact is high confidentiality loss (access to sensitive data and connected service outputs) and low integrity impact (ability to invoke tools that may modify data or trigger actions). Availability is not directly impacted. Depending on the MCP tools configured — which may include integrations with databases, code execution environments, or third-party APIs — the blast radius could extend significantly beyond the LiteLLM proxy itself (Github Advisory, GHSA Advisory).

The vulnerability is exploitable by unauthenticated network attackers with no user interaction required and low attack complexity, making it highly automatable (NVD SSVC: Automatable=yes). The EPSS score is approximately 0.243% (16th percentile). No public proof-of-concept exploit code has been confirmed, though exploitation has been reported by various sources including coverage by Sysdig (Github Advisory). The vulnerability is not currently listed in the CISA KEV catalog. Qualys has added detection for this vulnerability (detection ID 531798).

1. Reconnaissance: Identify internet-facing LiteLLM proxy instances running versions prior to 1.84.0 using tools like Shodan or Censys, searching for LiteLLM-specific response headers or endpoints.
2. Identify MCP endpoint: Probe for the MCP Streamable HTTP endpoint, typically accessible at /mcp/ or /{server_name}/mcp paths on the LiteLLM proxy.
3. Craft fabricated Authorization header: Construct an HTTP request with a fabricated Authorization: Bearer <arbitrary_token> header containing any non-empty, invalid Bearer token value.
4. Trigger OAuth2 fallback: Send the crafted request to an MCP endpoint (e.g., POST /mcp/tools/list). The LiteLLM auth handler attempts to validate the token, receives a 401/403, and — in vulnerable versions — falls back to creating an empty UserAPIKeyAuth() object instead of rejecting the request.
5. Enumerate MCP tools: With the anonymous session established, send requests to list all configured MCP tools (e.g., tools/list MCP method) to discover available integrations and capabilities.
6. Invoke MCP tools: Call specific MCP tools (e.g., tools/call) to access connected services, exfiltrate data, or trigger actions on integrated systems (GitHub PR, GHSA Advisory).

• Network: Unexpected HTTP requests to /mcp/, /{server_name}/mcp, or /mcp/{server_name} endpoints from unknown or external IP addresses; requests containing Authorization: Bearer headers that do not correspond to valid LiteLLM API keys.
• Logs: LiteLLM proxy access logs showing MCP endpoint requests (e.g., tools/list, tools/call) from unauthenticated or unrecognized sources; debug log entries containing "MCP OAuth2: Authorization header is not a valid LiteLLM key, treating as OAuth2 token passthrough" from pre-patch versions.
• Logs: Unusual volume of MCP tool enumeration requests (tools/list) followed by tool invocation calls (tools/call) in a short time window, suggesting automated scanning or exploitation.
• Application Behavior: MCP tool calls succeeding without corresponding valid API key entries in the LiteLLM key management database; unexpected outbound connections from the LiteLLM proxy to MCP-connected backend services.

Upgrade LiteLLM to version 1.84.0 or later, which contains the fix for both the public-route smuggling bypass and the OAuth2 fallback fail-open behavior (GitHub Release). As an immediate workaround if patching is not possible, disable MCP routes entirely or block access to /mcp/ and all related MCP endpoints at your reverse proxy or API gateway to prevent unauthenticated access (GHSA Advisory). Additionally, restrict network access to the LiteLLM proxy's MCP endpoints to trusted internal sources only, and monitor access logs for suspicious Authorization header usage on MCP paths.

Sysdig flagged this as a critical LiteLLM vulnerability in their AI security coverage, highlighting the risk to organizations using LiteLLM as an AI gateway with MCP integrations. The vulnerability was reported by security researcher yaaras and disclosed through GitHub's security advisory process. The fix was developed by contributor stuxf and reviewed with a 5/5 confidence score by Greptile AI, which noted both security fixes were correctly implemented and thoroughly tested (Github Advisory, GitHub PR).