Act nowKnown exploited

Advisory · CVE-2026-59822

LiteLLM's MCP door accepts any fake badge

An OAuth2 passthrough fallback in LiteLLM's MCP Streamable HTTP endpoint lets an unauthenticated attacker use a fabricated Bearer token to establish an authenticated MCP session and reach configured tools.

Advisory published September 2, 2026Independent summary
Vendor
BerriAI
Product
LiteLLM
Identifier / CWE
CVE-2026-59822
CWE-287, CWE-306
Action timing
Sep 23, 2026
ELI5

Explain it like I’m five

The front desk is supposed to check your membership card, but when the card reader glitches it hands you a blank guest pass instead of turning you away. Anyone holding a scribbled note gets full member access to the tool room.

SIMPLIFIED_ATTACK_PATH04 STEPS
  1. 01Fabricated token

    An unauthenticated attacker sends a request to the MCP Streamable HTTP endpoint with a fabricated Authorization Bearer header.

  2. 02Key validation fails

    LiteLLM key validation fails, triggering the OAuth2 passthrough fallback path.

  3. 03Empty auth object

    The fallback replaces the failed validation with an empty UserAPIKeyAuth object instead of rejecting the request.

  4. 04MCP session opened

    The request reaches MCP tooling as an authenticated session, letting the attacker list and call configured MCP tools and connected services.

What happened

On September 2, 2026, CISA added CVE-2026-59822 to the Known Exploited Vulnerabilities catalog. It is an improper authentication flaw in LiteLLM, the AI gateway proxy, rated high at CVSS 8.8 under CVSS v4.0, fixed in version 1.84.0.

LiteLLM’s MCP Streamable HTTP endpoint supported OAuth2 passthrough for upstream MCP servers. When a request arrived with a fabricated Authorization header, LiteLLM key validation failed as expected, but the fallback path then replaced the failed validation with an empty UserAPIKeyAuth() object rather than rejecting the request. That empty object passed the request through to MCP tooling as an authenticated session. An unauthenticated attacker could therefore establish an MCP session with an arbitrary Bearer token and use it to list and call configured MCP tools, reaching whatever connected services those tools expose.

The project’s advisory recommends upgrading to 1.84.0 or later. If upgrading is not immediately possible, the documented workaround is to disable MCP routes or block access to /mcp/ and related MCP endpoints at the reverse proxy or API gateway.

What to do

  1. Upgrade LiteLLM proxy deployments to 1.84.0 or later.
  2. If the upgrade must wait, disable MCP routes or block /mcp/ and related MCP endpoints at your reverse proxy or API gateway as the advisory’s interim workaround.
  3. Review proxy and MCP access logs for requests with unusual or fabricated Authorization headers and for MCP tool invocations that do not map to legitimate users or keys.
  4. Inventory which MCP tools and connected services were reachable through the proxy; assume anything those tools could touch was exposed and review its logs as well.
  5. Rotate LiteLLM keys and any credentials held by connected MCP services if unauthorized sessions cannot be ruled out.
  6. Confirm the running version and verify MCP endpoints require valid keys after the change.

Management note

LiteLLM sits in front of your AI infrastructure and your keys, so an authentication bypass there hands attackers a skeleton key to every MCP-connected service behind it. The fix is a one-version upgrade and the workaround is a firewall rule, but the scoping question is the real work: MCP tools often reach databases, ticketing systems, and cloud accounts, and each of those inherits the exposure. Patch fast and audit what the proxy could reach.