// threat brief

CVE-2026-59822Actively exploited

LiteLLM Proxy MCP gateway authentication bypass: any made-up token can call MCP tools

CVSS: 8.2 HIGH
CISA KEV: 2026-09-02
Weakness: CWE-287 · CWE-306
Topics: AI security

PlainCVE Team · Published 2026-09-23 · Updated 2026-09-24 · AI-assisted · Press brief ↓

Human review 2026-09-23Command tests: none yetReproduced: not yetVerification record ↓

LiteLLM Proxy's MCP endpoints let failed logins through as anonymous, so anyone can list and call its MCP tools with no account. Exploited in the wild.

Who is affected	Organizations running LiteLLM Proxy before 1.84.0 with MCP servers configured, where the MCP routes are reachable from an untrusted network.
What happens	An attacker can use the gateway to operate the MCP tools and services you've connected, such as reading and writing tickets, code repositories, or databases. What they can do depends on which tools you've connected.
What to do now	Upgrade litellm to 1.84.0 or later. If you can't upgrade right away, block the /mcp/ paths at your reverse proxy or API gateway. View evidence(4) Vendor / maintainerBerriAI's advisory: upgrade to 1.84.0 or laterWe recommend upgrading to 1.84.0 or later.github.com Vendor / maintainerBerriAI's advisory: if you cannot upgrade right away, disable or block /mcp/ and related endpoints at your reverse proxy or API gatewayIf upgrading is not immediately possible, disable MCP routes or block access to /mcp/ and related MCP endpoints at your reverse proxy or API gateway.github.com ResearchersSkycloak recommends rotating every upstream model provider key the gateway held; this is a researcher's suggestion, and the vendor gives no rotation guidanceskycloak.io Our assessmentExcluding legitimate passthrough to OAuth2 servers when reviewing logs, and rotating the affected MCP servers' credentials only after suspicious access, is our own response advice drawing on Skycloak; the vendor gives no detection guidance
Affected versions	All versions before 1.84.0 View evidence(3) Vendor / maintainerBerriAI's advisory: the MCP endpoint lets anyone open an authenticated MCP session with an arbitrary Bearer token, affecting versions before 1.84.0LiteLLM's MCP Streamable HTTP endpoint could allow an unauthenticated attacker to establish an authenticated MCP session using an arbitrary Bearer token.github.com CVE recordThe CVE record: versions before 1.84.0 are affectedPrior to 1.84.0, LiteLLM's MCP Streamable HTTP endpoint allowed an unauthenticated attacker to use a fabricated Authorization headercve.org Vendor / maintainerBerriAI's advisory: attackers can list and call the configured MCP tools, so exposure depends on having MCP servers configuredAn attacker could use this to list and call configured MCP tools and access connected services exposed through MCP.github.com
Fixed versions	1.84.0 or later View evidence(3) Vendor / maintainerBerriAI's advisory: fixed in 1.84.0The issue is fixed in 1.84.0.github.com Vendor / maintainerThe litellm v1.84.0 release notes include the fix, PR #26463fix(mcp): tighten public-route detection and OAuth2 fallback gatinggithub.com CVE recordThe CVE record: fixed in 1.84.0This issue is fixed in version 1.84.0.cve.org
CVSS vector	Show full vector `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N`
Timeline	Introduced 2026-02-07 · 1.81.9 released, first version with PR #20602 source First public 2026-06-30
CISA KEV	Listed (2026-09-02): attacks have been seen in the wild View evidence(3) CERT / governmentCISA added it to KEV on 2026-09-02 based on evidence of active exploitationbased on evidence of active exploitationcisa.gov ResearchersWiz observed this vulnerability being exploited in its honeypotsWe observed exploitation of this vulnerability in our honeypotswiz.io Our assessmentSome news reports call this the first MCP-related vulnerability added to KEV; CISA itself does not say so, and we do not repeat that claim

Blue team playbook

Check, fix / mitigate, respond, harden. Matching the affected versions does not mean you were compromised, and a check that finds nothing does not prove you are safe; each item says what it can and cannot show. Tagged steps point to where the attack flow below can be stopped.

DETECTCheckAm I affected? Any signs of compromise?

01Check your version and exposure
You are affected only if all three hold: LiteLLM Proxy before 1.84.0, MCP servers configured, and MCP routes reachable from untrusted networks.
Read-only check
```
pip show litellm | grep -i '^version'
```
02Look for signs of exploitation
First exclude legitimate passthrough to MCP servers configured for OAuth2 (those tokens are never LiteLLM keys, and the fix still allows them). Then investigate non-OAuth2 targets that accepted unknown tokens, unusual tool calls, and the authorization results on the upstream services. A token that matched no LiteLLM key but succeeded is not, on its own, proof of compromise.
Step 2 Step 3

MITIGATEFix / mitigatePatch; block it if you cannot patch yet

01Upgrade to 1.84.0 or later
After the fix, passthrough is allowed only when every target server is configured for oauth2; everything else is rejected.
Changes your environment
```
pip install -U "litellm>=1.84.0"
```
Step 3
02Can't upgrade yet: block /mcp/ at the reverse proxy
Official advice: disable or block /mcp/ and related endpoints at your reverse proxy or API gateway.
Step 1

RESPONDRespondIf you find signs of compromise

01Rotate credentials of connected services
If you confirm suspicious access, rotate the credentials of the affected MCP servers; Skycloak also recommends rotating the upstream model provider keys the gateway held. This is a precautionary suggestion from PlainCVE, not a confirmation that keys leaked; the project has published no rotation guidance.
Step 4

HARDENHardenPrevent the next one

01Don't expose AI gateways directly to the internet
Step 1
02Give each MCP tool least-privilege credentials
Even if the gateway is bypassed, what an attacker can do stays limited.
Step 4

Full remediation steps and notes

Upgrade. pip install -U "litellm>=1.84.0", or update the Proxy’s Docker image to the matching version.
If you can’t upgrade right away. The official advice: disable or block the /mcp/ endpoints at your reverse proxy or API gateway.
Check whether you were exploited. The project has not published detection or rotation guidance; what follows is PlainCVE’s suggested response, drawing on Skycloak’s analysis. When reviewing MCP endpoint logs, first exclude requests passed through to MCP servers configured for OAuth2: those tokens are never LiteLLM keys, and the fix still allows them. Then investigate non-OAuth2 targets that accepted unknown tokens, unusual tool calls, and the authorization results on the upstream services. Don’t start a full credential rotation just because a token matched no LiteLLM key and the request succeeded. If you confirm suspicious access, rotate the credentials of the affected MCP servers; Skycloak also recommends rotating every upstream model provider key the gateway held. This is a precaution, not a confirmation that keys leaked.
General principles. Don’t expose AI gateways directly to the internet; use least-privilege credentials for each MCP tool.

Attack flow

Read left to right: this is the order the attack happens in. A blue shield means the step can be stopped; the earlier, the better. Click an icon for details.

Free to use in reporting and teaching under CC BY 4.0. Attribution is already on the image.

Attacker
Calls an MCP endpoint with a made-up token
No LiteLLM account or key is needed.
Defense: Use a reverse proxy or API gateway to allow /mcp/ access only from the internal network.
Your system
LiteLLM checks the token, and the check fails
Normally it should return 401 here.
Your system
The failed check is let through as "OAuth2 passthrough"
Older versions assumed a token that failed the check was an OAuth2 token meant to be forwarded to an upstream MCP server, so they carried on with a blank anonymous identity, and did so for every MCP server.
Defense: Upgrade to 1.84.0+, where this passthrough is allowed only for servers configured as oauth2 and everything else is rejected.
External
The attacker lists and calls the connected MCP tools
Servers configured with allow_all_keys are opened up to the anonymous identity even more directly.
Defense: Connect only the MCP tools you need, and give each tool least-privilege credentials.

Who is affected

Condition	Affected?
LiteLLM Proxy before 1.84.0 + MCP servers configured + MCP routes reachable from outside	Affected
LiteLLM Proxy 1.84.0 or later	Fixed
Using litellm only as a Python SDK to call models, without running the Proxy	The official advisory describes the Proxy’s MCP endpoints
Running the Proxy without any MCP servers configured	There are no MCP tools to call, but upgrading is still recommended

How it works

LiteLLM Proxy can sit in front of multiple MCP servers as a gateway. Some upstream MCP servers use their own OAuth2 login, so LiteLLM needs to “pass through” the user’s OAuth token to them rather than checking it as one of LiteLLM’s own keys.

A piece of compatibility logic added in February 2026 was far too lenient: whenever a request carried an Authorization header but failed LiteLLM’s own key check, the code assumed it was an OAuth2 token to be passed through and carried on with a blank anonymous identity. This assumption applied to every MCP server, not just the ones actually configured for OAuth2.

The result: make up any token, fail the check, and get let through anyway. This kind of mistake is called “fail-open,” and it maps to CWE-287 (improper authentication) and CWE-306 (missing authentication for critical function).

The flawed approach (conceptual illustration, not the original source code):

Show code example(python)

try:
    identity = verify_litellm_key(token)
except AuthError:
    # Check failed → treat it as an OAuth2 token to pass through and carry on anonymously
    identity = AnonymousIdentity()

The fixed approach:

Show code example(python)

try:
    identity = verify_litellm_key(token)
except AuthError:
    # Allow passthrough only if "every target server is explicitly configured as oauth2"; reject everything else
    if targets and all(s.auth_type == "oauth2" for s in targets):
        identity = AnonymousIdentity()
    else:
        raise

The same fix also addressed a second problem: when deciding whether a path was “public” (.well-known), the code matched against the whole URL, including the query string, instead of just the path.

Timeline

Date	Event
2026-02-06	OAuth2 passthrough compatibility logic added (PR #20602), introducing the problem
2026-04-30	Fix PR #26463 merged
2026-05-14	v1.84.0 released
2026-06-30	GitHub security advisory published
2026-07-08	CVE published
2026-08-27	Wiz publishes research from its AI infrastructure honeypot, observing real attack traffic
2026-09-02	CISA adds it to the Known Exploited Vulnerabilities catalog

Verification Reviewed and checked against sources; not yet reproduced in our lab

Reviewed	2026-09-23

Verification records describe the environment and the result only, never reproduction steps or code that could attack other people’s systems. See our policy.

Sources

Other1.81.9 released, first version with PR #20602 · pypi.org · accessed 2026-09-24
AdvisoryGHSA-7488-6r32-c95q — MCP Authentication Bypass via OAuth2 Passthrough Fallback · BerriAI (GitHub), 2026-06-30 · accessed 2026-09-23
CVE / NVD / OSVCVE-2026-59822 Record · CVE Program, 2026-07-08 · accessed 2026-09-23
CVE / NVD / OSVNVD - CVE-2026-59822 · NIST · accessed 2026-09-23
NVD's CVSS 3.1 score is 8.2; the CNA (GitHub) CVSS 4.0 score is 8.8.
AdvisoryCISA Adds Seven Known Exploited Vulnerabilities to Catalog · CISA, 2026-09-02 · accessed 2026-09-23
Patch / releasefix(mcp): tighten public-route detection and OAuth2 fallback gating (PR #26463) · BerriAI (GitHub), 2026-04-30 · accessed 2026-09-23
Patch / releaselitellm v1.84.0 release · BerriAI (GitHub), 2026-05-14 · accessed 2026-09-23
Patch / releasefix(mcp): resolve OAuth2 'Capabilities: none' bug for upstream MCP servers (PR #20602) · BerriAI (GitHub), 2026-02-06 · accessed 2026-09-24
ResearchCVE-2026-59822: LiteLLM's MCP Auth Bypass, and the Second Bug in the Same Fix · Skycloak, 2026-09-21 · accessed 2026-09-24
ResearchInside 90 days of attacks on AI infrastructure · Wiz Research, 2026-08-27 · accessed 2026-09-23

Press brief

In one sentence

LiteLLM is an open-source gateway that many companies use to manage their AI model calls in one place. Its MCP feature, which connects to external tools, had an authentication flaw: requests that failed verification were let through as if they were legitimate. The US agency CISA added it to its Known Exploited Vulnerabilities catalog on September 2, 2026. The fixed version, 1.84.0, was released in May.

Key facts

Severity: CVSS 3.1 8.2 (NVD) nvd.nist.gov
Added to CISA KEV: 2026-09-02 cisa.gov
Fixed version: 1.84.0 (released 2026-05-14) github.com
Advisory published: 2026-06-30 github.com

Confirmed

Requests that fail authentication are let through as an anonymous identity on the MCP endpoints of LiteLLM Proxy before 1.84.0.
CISA has added it to the Known Exploited Vulnerabilities catalog.
Wiz's honeypot research observed real attack traffic against AI infrastructure.

Unconfirmed / disputed

Some news reports call this the first MCP-related flaw in KEV; CISA itself has not said so.
The official advisory does not say upstream model provider API keys can be read, and this page does not assume it.

Quotable line

The problem with this vulnerability isn't a weak password. It's that when the lock broke, the door was left open instead of locked.

Images

Download the share image (PNG) · Attack flow diagram (downloadable)

Please credit "PlainCVE" and link to this page. Full citation format is under "How to cite" below. Found a factual error? Report it.

LiteLLM Proxy MCP gateway authentication bypass: any made-up token can call MCP tools

LiteLLM is an open-source gateway that many companies use to manage their AI model calls in one place. Its MCP feature, which connects to external tools, had an authentication flaw: requests that failed verification were let through as if they were legitimate. The US agency CISA added it to its Known Exploited Vulnerabilities catalog on September 2, 2026. The fixed version, 1.84.0, was released in May.

Key facts:
- Severity:CVSS 3.1 8.2 (NVD)(https://nvd.nist.gov/vuln/detail/CVE-2026-59822)
- Added to CISA KEV:2026-09-02(https://www.cisa.gov/news-events/alerts/2026/09/02/cisa-adds-seven-known-exploited-vulnerabilities-catalog)
- Fixed version:1.84.0 (released 2026-05-14)(https://github.com/BerriAI/litellm/releases/tag/v1.84.0)
- Advisory published:2026-06-30(https://github.com/BerriAI/litellm/security/advisories/GHSA-7488-6r32-c95q)

Confirmed:
- Requests that fail authentication are let through as an anonymous identity on the MCP endpoints of LiteLLM Proxy before 1.84.0.
- CISA has added it to the Known Exploited Vulnerabilities catalog.
- Wiz's honeypot research observed real attack traffic against AI infrastructure.

Unconfirmed / disputed:
- Some news reports call this the first MCP-related flaw in KEV; CISA itself has not said so.
- The official advisory does not say upstream model provider API keys can be read, and this page does not assume it.

「The problem with this vulnerability isn't a weak password. It's that when the lock broke, the door was left open instead of locked.」— PlainCVE
https://plaincve.date/en/vulns/cve-2026-59822-litellm-mcp-auth-bypass

How to cite this page

This article is CC BY 4.0. Please keep the attribution and link when republishing.

PlainCVE Team (2026). "LiteLLM Proxy MCP gateway authentication bypass: any made-up token can call MCP tools". PlainCVE. https://plaincve.date/en/vulns/cve-2026-59822-litellm-mcp-auth-bypass (accessed YYYY-MM-DD)

BibTeX

@misc{cve202659822litellmmcpauthbypass2026,
  title  = {LiteLLM Proxy MCP gateway authentication bypass: any made-up token can call MCP tools},
  author = {PlainCVE Team},
  year   = {2026},
  howpublished = {PlainCVE},
  url    = {https://plaincve.date/en/vulns/cve-2026-59822-litellm-mcp-auth-bypass},
  note   = {Updated 2026-09-24}
}