BerriAI LiteLLM MCP authentication bypass through OAuth2 passthrough fallback

LiteLLM is a proxy server (AI Gateway) to call LLM APIs in OpenAI (or native) format. Prior to 1.84.0, LiteLLM's MCP Streamable HTTP endpoint allowed an unauthenticated attacker to use a fabricated Authorization header to trigger an OAuth2 passthrough fallback path that replaced failed LiteLLM key validation with an empty UserAPIKeyAuth() object, allowing requests to reach MCP tooling without a valid LiteLLM key. This issue is fixed in version 1.84.0.

• The BerriAI PyPI package litellm is affected in versions < 1.84.0.
• The confirmed fixed version is 1.84.0.
• The relevant scope is the MCP Streamable HTTP endpoint and MCP authentication logic supporting OAuth2 passthrough. Deployments that do not enable or expose MCP routes should still be checked to confirm that the vulnerable path is unreachable; the evidence does not establish safety solely from an endpoint not being advertised.
• The vendor fix also tightens public-route detection in the same MCP handler. The status of custom builds, parallel branches, or configurations not represented in the record must be verified separately.

BerriAI LiteLLM performs separate MCP authentication for its MCP Streamable HTTP endpoint. When a request contains an Authorization header but LiteLLM key validation fails with a 401 or 403 response, the OAuth2 passthrough fallback can treat that header as a token intended for an upstream MCP server and replace the authentication failure with an empty UserAPIKeyAuth() object. A fabricated Bearer token can therefore turn a failed authentication attempt into an accepted MCP session, allowing the request to reach MCP tooling without a valid LiteLLM key.

The vulnerable service must expose a reachable MCP Streamable HTTP endpoint, and the request must enter the fallback path described above. The vendor fix limits the fallback to cases where every MCP server targeted by the request is explicitly configured with auth_type=oauth2; unresolved targets and targets using other authentication modes retain the authentication failure. The same handler change also replaces a full-URL substring check for .well-known with a path-prefix check for /.well-known/, preventing public-route detection from being bypassed through a query string, hostname, or unrelated path segment. The supplied CVE description focuses on the OAuth2 passthrough fallback, so deployment-specific MCP server configuration still needs to be reviewed.

The vulnerability is remotely exploitable over the network against a reachable MCP endpoint. No prior authentication, special privileges, or user interaction are required, and the recorded attack complexity is low. The primary attack vector is an Authorization header containing a fabricated Bearer token that triggers the OAuth2 passthrough fallback after LiteLLM key validation fails.

The supplied record marks the vulnerability as known exploited and as having a public exploit. Wiz also reports observing exploitation through honeypot infrastructure. The available evidence does not identify particular victims, campaigns, or affected organizations.

Successful exploitation causes LiteLLM to treat the request as an authenticated MCP session even though the caller does not possess a valid LiteLLM key. The attacker may enumerate and invoke MCP tools exposed through the proxy, which can provide access to data or permit state changes in connected services when those tools support such operations.

The technical consequences can include loss of confidentiality for data supplied through MCP and loss of integrity where tools can modify state. The record does not describe a direct availability impact. The final scope depends on the targeted MCP servers, individual tool permissions, and the data or actions exposed by downstream services.

An attacker can use the unauthorized MCP session to enumerate configured tools and invoke them. Depending on the available tools, consequences may include reading data from connected services, accessing sensitive service outputs, or performing state-changing operations when a tool permits them.

The practical blast radius depends on the MCP servers, tool permissions, and downstream systems configured behind LiteLLM. The available record does not establish that every deployment permits code execution, complete host compromise, or service disruption; those possibilities must be assessed against the actual deployment configuration.

1. Upgrade litellm to version 1.84.0, the release confirmed to contain the fix.
2. If immediate upgrading is not possible, disable MCP routes or block /mcp/ and related MCP endpoints at the reverse proxy or API gateway.
3. Restrict network access to MCP endpoints to trusted sources, and review the configuration so OAuth2 passthrough is enabled only for MCP servers intentionally configured with auth_type=oauth2.
4. Because the supplied record marks the vulnerability as known exploited, review access logs, audit trails, and MCP-server activity from before the fix was deployed. Investigate unexpected MCP requests or tool calls that lack a corresponding valid identity.

1. Inventory all litellm installations, verify their versions, and identify systems with MCP Streamable HTTP enabled or exposed. Installations in the < 1.84.0 range should be prioritized for review.
2. Review reverse-proxy, API-gateway, and firewall rules for /mcp/ and related MCP endpoints that are reachable from the Internet or other untrusted networks.
3. Examine access and audit logs for MCP requests carrying an Authorization: Bearer value that does not correspond to a valid LiteLLM key, especially when the request still performs tools/list or tools/call operations.
4. Correlate successful MCP calls with valid identities, API keys, and authorization records. The absence of suspicious log entries does not prove that the deployment was not exploited.
5. Verify MCP target configuration and confirm that servers using OAuth2 passthrough are intentionally configured with auth_type=oauth2. Also review MCP requests where .well-known appears in a query string, hostname, or location other than the /.well-known/ path prefix, because the vendor fix addresses this related public-route condition in the same handler.