LiteLLM MCP authentication bypass via OAuth2 passthrough fallback (CVE-2026-59822)
LiteLLM's MCP authentication handler could replace a failed key validation with an empty, accepted UserAPIKeyAuth object under its OAuth2 passthrough fallback, letting a request carrying a fabricated Bearer token reach configured MCP tooling without a validly established identity. Disclosed and patched in LiteLLM 1.84.0. CISA added it to the Known Exploited Vulnerabilities catalog on 2 September 2026, evidence of active exploitation with no incident level detail established.
Affected
- Organisation
- BerriAI
- Product
- LiteLLM
- Component
- MCP Streamable HTTP endpoint authentication handler, OAuth2 passthrough fallback
- Versions
- Versions before 1.84.0; fixed in 1.84.0
- Configurations
- LiteLLM's MCP proxy enabled with at least one upstream MCP server configured; The LiteLLM MCP Streamable HTTP endpoint reachable by an untrusted network caller
Execution authority facts
Fields the evidence does not establish are shown as unknown rather than guessed.
- Intended task
- A network caller reaching LiteLLM's MCP Streamable HTTP endpoint
- Agent
- unknown
- Delegating actor
- unknown
- Action
- Sent a request carrying a fabricated value in the Authorization: Bearer header, which failed LiteLLM's own key validation, then continued to configured MCP tooling through the OAuth2 passthrough fallback's synthesized empty identity
- Target resource
- MCP servers and tools configured behind the affected LiteLLM deployment
- Environment
- Wherever the LiteLLM MCP Streamable HTTP endpoint is deployed and reachable
- Credentials used
- A fabricated Bearer token value, not a credential issued by the operator
- Privileges available
- unknown
- Authority presented
- An empty UserAPIKeyAuth object the vulnerable fallback constructed after the caller's own credential failed validation
- Authority required
- A LiteLLM issued key, or a token from an upstream MCP server the operator had explicitly configured for OAuth2 passthrough
- Applicable policy
- LiteLLM's own MCP request key validation
- Approval mechanism
- unknown
- Required approver
- unknown
- Independent approval
- unknown
- Action binding
- The fallback's own precondition, that the request's target MCP server was configured for OAuth2 passthrough, was not checked before the fallback fired
- Sequence context
- A single request to the MCP endpoint; LiteLLM's ordinary key validation failed, and the vulnerable exception path substituted a constructed identity rather than propagating the rejection
Impact
- Consequence
- Configured MCP tooling and connected services became reachable through an identity the gateway constructed after the caller's own credential failed validation
- Reach
- Configuration dependent: whichever MCP servers and tools an operator had configured behind the affected LiteLLM deployment
- Reversibility
- unknown
- Detectability
- unknown
- Propagation
- unknown
- Recovery
- Fixed in LiteLLM 1.84.0, which restricts the fallback to requests whose resolved target MCP servers are all explicitly configured for OAuth2 passthrough; a published workaround for operators who cannot upgrade immediately is to disable or block the affected MCP routes at a reverse proxy or gateway
Evidence
Primary sources
- CVE-2026-59822: LiteLLM: MCP Authentication Bypass via OAuth2 Passthrough Fallback (BerriAI, litellm (GitHub Security Advisory GHSA-7488-6r32-c95q))
- fix(mcp): tighten public-route detection and OAuth2 fallback gating (#26463) (BerriAI, litellm (GitHub))
Supporting sources
- CISA Adds Seven Known Exploited Vulnerabilities to Catalog (CISA)
- Known Exploited Vulnerabilities Catalog (CISA)
- Reproduction status
- Confirmed and patched by BerriAI; CVSS 4.0 base 8.8 in the GitHub advisory. CISA added CVE-2026-59822 to its Known Exploited Vulnerabilities catalog on 2 September 2026, its own evidence of active exploitation.
- Evidence state
- Confirmed
Known unknowns
- Which MCP tool, if any, an exploiting caller invoked.
- Whether any specific organisation's deployment was exploited, and what, if anything, was reached once inside.
- Whether the separate .well-known public route check fixed in the same commit was itself independently exploited.
Limitations
- CISA's Known Exploited Vulnerabilities catalog is evidence of active exploitation; it does not itself carry incident level detail, and this record found none independently.
- This CVE's own GitHub Security Advisory is scoped to the OAuth2 passthrough fallback. A separate, uncredentialed .well-known public route bypass fixed in the same commit is recorded on the source record as supporting implementation evidence rather than folded into this entry.
- www.cisa.gov is blocked to direct fetch from this session; the KEV addition is corroborated through independently phrased search passes rather than a direct read of the CISA page.
Claim provenance
- verified
GitHub's advisory assigns CVE-2026-59822 and CWE-287 and records CVSS 4.0 base 8.8; the linked pull request and its fixing commit, read directly, gate the OAuth2 fallback to requests whose resolved target MCP servers are all explicitly configured for it.
The Token Was Invalid. The Gateway Let the Caller Through Anyway. - independent-reporting
www.cisa.gov is blocked to direct fetch from this session. The 2 September 2026 Known Exploited Vulnerabilities catalog addition is corroborated through independently phrased search passes rather than a direct read of the CISA page itself.
The Token Was Invalid. The Gateway Let the Caller Through Anyway.
Protocol evidence
Published authority architectures whose artifacts bear on the requirement this vulnerability exposes: which satisfy it, which expose a way past it, and which leave it unanswered.
- Supports requirement
Agent Control Standard (ACS)
OWASP GenAI Security Project, originally Zenity
Requirement The default posture when no decision arrives in time is to proceed, not to block
LiteLLM is not an ACS implementation, and this link does not claim it is. ACS's specification states its own tradeoff in fail open decision handling directly: a disrupted or unreachable Guardian defaults to proceed unless a deployment opts into failing closed. LiteLLM's own MCP authentication fallback shows the same tradeoff realised at a different boundary, a failed credential check rather than an unreachable decision service, and CISA's Known Exploited Vulnerabilities catalog addition is independent, real world evidence for exactly the risk ACS's specification names in its own words: an adversary able to trigger the failure path converts what was meant to be a control into something weaker.