LiteLLM’s Fake-Token Flaw: A Breach Story

This is a story about a door with a broken lock. The lock looked fine — it even asked for a key. But when you handed it the wrong key, instead of saying “no,” it quietly said “close enough” and let you in. That door is LiteLLM, a popular AI gateway, and the broken lock is CVE-2026-59822.

The victim: teams running an AI gateway

LiteLLM is an AI gateway — the software many companies put in front of their large language models to route requests, enforce API keys, and connect the model to tools and data through the Model Context Protocol (MCP). If your team wired an LLM to your databases, ticketing system, or cloud APIs so it could actually get things done, there is a good chance LiteLLM (or something like it) is sitting in the middle. Anyone running a LiteLLM version below 1.84.0 with its MCP endpoint reachable over the network is a potential victim.

The villain: a fallback that failed open

LiteLLM’s MCP endpoint is supposed to check a Bearer token before it lets a request reach your AI tools. To support forwarding credentials to upstream MCP servers, it added an “OAuth2 passthrough” mode. The flaw was in the fallback: when LiteLLM’s own key check failed, instead of rejecting the request, the code fell back to an empty authentication object — and the rest of the system trusted that empty object as a valid, authenticated user.

This is the worst kind of security bug: it fails open. A failed check should always end in “access denied.” Here, a failed check ended in “welcome in.” It is catalogued as CWE-287 (Improper Authentication) plus CWE-306 (Missing Authentication for a Critical Function), and it carries a CVSS score of 8.8.

# LiteLLM MCP auth, conceptually:
auth = validate_litellm_key(bearer_token)
if not auth:
    # THE BUG: a FAILED check falls through to an empty "user"...
    auth = UserAPIKeyAuth()   # ...which the rest of the code trusts as valid
# -> the request now reaches your MCP tools with no real identity

The practical result: an attacker sends a request carrying any made-up token — literally “Bearer NOT-A-REAL-TOKEN” — and LiteLLM opens an authenticated MCP session for them.

The cost: your AI tools become the attacker’s tools

Once inside, the intruder can list and call every MCP tool the gateway exposes — and reach whatever those tools are wired to. If your MCP tools can read a database, hit an internal API, or touch cloud resources, so can the attacker. Depending on what you have connected, that spans quiet data exposure through to hands-on-keyboard access to internal systems. And because each request looks “authenticated,” it can slide past logging that only flags obviously anonymous traffic.

For anyone under a compliance program, it is also a direct control failure. It breaks SOC 2 CC6.6 (restrict and protect internet-facing access) and ISO 27001 A.8.5 (secure authentication) — the exact controls an auditor tests.

How the story plays out

• An attacker scans the internet for exposed MCP endpoints — they are easy to fingerprint.
• They send one request to /mcp carrying a fabricated Bearer token.
• LiteLLM’s key check fails, then falls back to an empty “authenticated” session.
• The server replies with a real session ID. The attacker is now “logged in.”
• They enumerate the available MCP tools and start calling the ones that reach data or systems.

How it was discovered

This one was found by security researchers and reported responsibly to BerriAI, LiteLLM’s maintainer, who published it as GitHub Security Advisory GHSA-7488-6r32-c95q and shipped a fix in version 1.84.0. It was serious enough that CISA added it to its Known Exploited Vulnerabilities catalog on September 2, 2026 — meaning it is not theoretical, it is being used in the wild. That is the good version of this story: a researcher found it before the damage was widespread, and there is a patch. The bad version is every organization that has not applied it yet.

What the developers and QA would have done differently

This is the part worth dwelling on, because the bug is textbook and completely catchable. The mistake was not exotic — it was a missing test of the failure path.

1. Test the “no,” not just the “yes.”

Most authentication tests confirm that a good token works. Far fewer confirm that a bad token is refused. A single negative test — “send a garbage Bearer token, assert the response is 401” — would have failed loudly the moment this fallback was introduced. Every auth surface needs its abuse cases tested as first-class citizens, not just its happy path.

2. Deny by default in code review.

Any code path where a failed security check assigns a default or empty credential object is a red flag. The reviewer’s question is simple: “What happens when this check fails?” If the answer is anything other than “the request is refused,” it does not merge. Fail-closed is the rule; fail-open is the incident.

3. Threat-model the shortcut.

The bug lived inside a convenience feature — OAuth2 passthrough. New auth modes and fallbacks are exactly where these holes appear, because they add a second path around the main one. Any change that touches authentication deserves a short threat-modeling pass and an adversarial “how would I bypass this?” review before release.

How the victims could have protected themselves — before the CVE existed

You cannot patch a vulnerability you have not heard of yet. But good due diligence would have blunted this one long before September 2 — and it is the same due diligence that neutralizes the next one:

• Do not expose the MCP endpoint to the internet. An AI gateway’s tool interface should sit behind your network boundary or a zero-trust proxy, reachable only by the services that need it. If an attacker cannot reach /mcp, the fail-open bug never fires.
• Assume the vendor’s auth will fail one day, and put your own in front. An identity-aware proxy that enforces its own authentication means a single broken lock downstream is not the only lock on the door.
• Give MCP tools the least privilege that does the job. If a tool only needs read access to one dataset, an auth bypass reaches one dataset — not your whole estate.
• Know what you run and what it exposes. A dependency inventory (you are running LiteLLM, at this version) plus continuous attack-surface monitoring (this host is exposing /mcp to the internet) turns “we had no idea” into a ticket you close on a Tuesday.

Fix it now — the short checklist

• Upgrade LiteLLM to 1.84.0 or later. This is the actual fix.
• Until you can, restrict the MCP endpoint at the network layer so only trusted callers reach it.
• Check whether you are exposed: send a request to /mcp with a deliberately fake Bearer token — if you get a session back instead of a 401, you are vulnerable.
• Rotate keys and review what your MCP tools can reach, on the assumption sessions may have been opened without one.
• Add a negative auth test to your own CI so a future fail-open cannot ship silently.

CVE-2026-59822 is not really a story about LiteLLM. It is a story about a new, fast-moving attack surface — the AI infrastructure layer, where gateways, MCP servers and LLM tools are being connected to real systems faster than they are being secured. The lock will keep breaking. The teams that come through it fine are the ones who assumed it would.

About CATAAM — CATAAM unifies evidence-gated compliance (SOC 2, ISO 27001, ISO 42001, HIPAA, PCI-DSS) with internal and external attack-surface management and breach-and-attack simulation in one platform, so an exposed endpoint like this one becomes a finding you fix — not a headline you star in.

Frequently asked questions

What is CVE-2026-59822?

A critical (CVSS 8.8) authentication-bypass vulnerability in the AI gateway LiteLLM. Its MCP Streamable HTTP endpoint failed open: when the LiteLLM key check failed, the OAuth2 passthrough fallback substituted an empty authentication object that the rest of the code trusted, so an attacker could present any fabricated Bearer token and open an authenticated MCP session.

Which LiteLLM versions are affected, and what is the fix?

All LiteLLM versions below 1.84.0 are affected. The issue is fixed in 1.84.0 — upgrade to 1.84.0 or later. Until you can, restrict the MCP endpoint at the network layer so only trusted callers can reach it.

How do I know if I am vulnerable?

Send a request to your LiteLLM /mcp endpoint with a deliberately fake Bearer token. If the server returns a session (a session ID and a JSON-RPC result) instead of a 401 Unauthorized, you are vulnerable. Any LiteLLM below 1.84.0 with a network-reachable MCP endpoint should be treated as exposed until patched.

Is CVE-2026-59822 being actively exploited?

Yes. CISA added it to its Known Exploited Vulnerabilities (KEV) catalog on September 2, 2026, which means there is evidence of exploitation in the wild — it is not theoretical.

Why is MCP a growing security concern?

The Model Context Protocol connects LLMs to real tools and data (databases, internal APIs, cloud resources). That makes an MCP endpoint a high-value target: a single auth flaw does not just leak a chatbot transcript, it can hand an attacker the tools your AI uses to touch production systems. The AI infrastructure layer — gateways, MCP servers, LLM tooling — is being wired up faster than it is being secured.