# LiteLLM MCP gateway accepts any Bearer token after key validation fails

Source: https://startwithidentity.com/cves/cve-2026-59822/
Last updated: 2026-11-05
License: content by Start with Identity. Cite the source URL.

---

## What broke

LiteLLM is a proxy that sits between applications and LLM providers, and it can also front MCP tool servers. Its MCP auth handler supports OAuth2 passthrough so a client's token can be forwarded to an upstream MCP server. BerriAI's advisory, published June 30, 2026, says that when LiteLLM key validation failed, the fallback path substituted an empty `UserAPIKeyAuth()` object instead of rejecting the request. A request with a fabricated `Authorization` header could then "list and call configured MCP tools" on the Streamable HTTP endpoint without a valid LiteLLM key. Versions before 1.84.0 are affected. NVD scores it CVSS 3.1 8.2 and lists CWE-287 and CWE-306.

Wiz reported on August 27, 2026 that its honeypots recorded the flaw being used with single-character tokens such as `x`. The same report describes attackers on LiteLLM honeypots pulling the master key from process memory, reading `/app/litellm_config.yaml` and `/etc/litellm/.env`, and trying the default master key `sk-1234`, though it does not tie those steps to this CVE specifically. CISA added it to KEV on September 2, 2026.

## Why it matters

An AI gateway is a credential broker. It holds provider API keys and connections to internal services through MCP, and its own key is the only thing deciding who may use them. Here a failed check produced an identity instead of a refusal: any caller became a user with an empty, unscoped principal. A fallback that grants access on error is the same mistake as `alg: none` in a [JWT](https://startwithidentity.com/glossary/jwt/) verifier. [MCP authorization](https://startwithidentity.com/standards/mcp-authorization/) expects the server to validate every [bearer token](https://startwithidentity.com/glossary/bearer-token/) it accepts, not to assume a downstream server will.

## What to do

- Upgrade LiteLLM to 1.84.0 or later.
- Until then, disable MCP routes or block `/mcp/` and related MCP endpoints at a reverse proxy or API gateway, as the advisory recommends.
- Keep the proxy off the internet unless it must be public, and never run with the default master key.

## After you patch

- Rotate the LiteLLM master key and every provider [API key](https://startwithidentity.com/glossary/api-key/) the proxy stores, plus credentials of services exposed as MCP tools.
- Review proxy logs for MCP calls and `GET /v1/models` requests with very short or malformed Bearer tokens.

## Sources

- [NVD: CVE-2026-59822](https://nvd.nist.gov/vuln/detail/cve-2026-59822)
- [BerriAI security advisory GHSA-7488-6r32-c95q](https://github.com/BerriAI/litellm/security/advisories/GHSA-7488-6r32-c95q)
- [Wiz: AI infrastructure honeypot findings (August 27, 2026)](https://www.wiz.io/blog/ai-infrastructure-honeypot)
- [CISA Known Exploited Vulnerabilities catalog, added September 2, 2026](https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-59822)