CVE-2026-59822: LiteLLM's Second MCP Auth Bypass

CVE-2026-59822 lets an attacker skip LiteLLM’s authentication on its MCP endpoint using nothing but a Bearer token they invented. It’s fixed in LiteLLM 1.84.0, CISA added it to the Known Exploited Vulnerabilities catalog on September 2, and Wiz has already seen it used against honeypot infrastructure. It’s also, importantly, not the LiteLLM CVE we covered in June. Same gateway, same protocol, different bug.

What CVE-2026-59822 actually is

LiteLLM’s MCP Streamable HTTP endpoint supports OAuth2 passthrough for upstream MCP servers, meaning it can hand off a client’s OAuth token to whatever tool server sits behind the gateway rather than terminating auth itself. That’s a reasonable design for federating identity across a chain of services. The bug is in what happens when that handoff fails.

When LiteLLM’s own key validation fails, the fallback path doesn’t reject the request. It replaces the failed validation with an empty UserAPIKeyAuth() object, an authentication result that looks structurally valid to the rest of the code even though it represents nobody. Send a request with a fabricated Authorization header, trigger the fallback, and you get a session that passes every downstream check that only looks at “is there an auth object” rather than “is this auth object backed by anything real.”

That’s a specific, narrow kind of bug: not a missing check, but a wrong default on the failure path of a check that mostly works. It’s also a familiar shape. Fallback logic that quietly degrades from “reject” to “accept an empty credential” is one of the more common ways authentication code fails, precisely because the happy path gets tested far more than the failure path does.

Not the June bug. A different one, same neighborhood.

If you patched LiteLLM back in June or July, you already know this gateway’s MCP surface has had a bad year. It’s worth being exact about why this isn’t the same story repeating.

	CVE-2026-42271 (June)	CVE-2026-59822 (this one)
Root cause	Command injection in /mcp-rest/test/* endpoints	Broken OAuth2 fallback in MCP Streamable HTTP auth
Needed to exploit alone	Valid session (until chained with Starlette’s CVE-2026-48710)	Nothing. A fabricated Bearer token is sufficient on its own
Fixed in	1.83.7	1.84.0
What it gets an attacker	Remote code execution on the gateway host	An authenticated MCP session with no real credential behind it

The overlap is real: same product, same MCP feature area, both eventually reachable without valid credentials. But “we already dealt with LiteLLM’s MCP problem” is the wrong takeaway if the version running in production is anywhere between 1.83.7 and 1.84.0. That’s a gateway that closed one hole and is still standing next to the other.

What Wiz is actually seeing

Wiz runs honeypot infrastructure designed to look like real, exploitable deployments, and its telemetry on this CVE shows attackers using the bypass to probe model enumeration endpoints. That’s reconnaissance: figuring out which models a gateway proxies, what an authenticated session can see, before deciding whether a target is worth a deeper attack.

It’s a smaller blast radius than the outcome Microsoft documented for the June chain, where compromised gateways got hit with XMRig cryptominer binaries after attackers fingerprinted the host and killed off competing miners. Reconnaissance-only doesn’t mean low priority, though. It means the more damaging follow-on hasn’t been widely automated yet, not that the access isn’t real. A bug that lets someone map your AI infrastructure for free is a bug you want to close before that changes.

Fixing it

pip show litellm
# or, against a running gateway:
curl -s https://your-litellm-host/health/readiness | grep -i version

If the version is below 1.84.0 and MCP is enabled with any OAuth2-authenticated upstream server configured, upgrade:

pip install --upgrade "litellm>=1.84.0"

Restart the gateway process after upgrading. An updated package with the old process still running serves the old, vulnerable code path until it’s actually restarted, the same gap that matters for browser and server patches alike.

If you can’t upgrade immediately, disable OAuth2 passthrough for MCP connections at the configuration level, or block the MCP Streamable HTTP endpoint at your reverse proxy until you can. Neither is a substitute for the version upgrade, but both close the specific path this CVE depends on in the meantime.

The broader pattern worth noting

This is the second LiteLLM MCP vulnerability to land in CISA’s KEV catalog inside three months, and it shipped in the same September 2 batch as fresh CVEs in Starlette, JFrog Artifactory, Kestra, and SonicWall’s SMA1000 line. If your team runs an LLM gateway in front of production traffic, or you’ve built MCP servers into your AI tool integrations, that concentration of activity is the signal to treat MCP-adjacent components as a standing patch-tracking item, not a one-time fire drill you handled back in June. The protocol is new enough that its authentication edge cases are still being found in production, and gateways sitting in front of every provider API key you hold are exactly the wrong place to be running six-month-old code.