LiteLLM Just Took Its Third CISA KEV Entry. This One Is an MCP Auth Bypass — and in April We Published That We Don't Use MCP. We Do Now.
- Patrick Duggan
- 1 minute ago
- 6 min read
CISA added CVE-2026-59822 to the Known Exploited Vulnerabilities catalog on September 2. It is the third LiteLLM entry on that list in under four months. Federal agencies have until September 16.
We have written the first two up. May 10, when the SQL injection landed and we could show we had indexed the poisoned versions six weeks earlier. June 16, when the command injection made it two entries in thirty-one days. This is the third, and the pattern is no longer the story. What the bug actually is, is the story.
The bug
Before version 1.84.0, LiteLLM's MCP Streamable HTTP endpoint accepted an Authorization header, tried to validate it as a LiteLLM key, and when that validation failed, fell through to an OAuth2 passthrough path that replaced the failed result with an empty user object. Not a rejection. An empty UserAPIKeyAuth() — a valid-shaped credential representing nobody.
The request then continued, because from that point forward everything downstream was looking at a well-formed authorization object and had no way to know it was manufactured by the failure handler.
So an unauthenticated attacker sends a made-up Authorization header, the validator rejects it, and the rejection is converted into an identity. From there they can list and call every MCP tool the gateway has configured, and reach every service behind them. Network vector, no privileges, no user interaction. Two public proof-of-concept exploits are already on GitHub.
The failure mode is not "the check was missing." The check ran. The check worked. The check said no, and the code caught the no and turned it into a yes.
Why this one is different from the other two
LiteLLM is a proxy that sits in front of every model an organization uses and holds all the keys. We said that in June and it is still the reason these entries matter more than their CVSS scores suggest.
But the first two were a database bug and a command execution bug — bad, ordinary, the kind of thing any web service gets. This one is a bug in the part that decides who you are, on the endpoint that exposes tools to AI agents. The blast radius is not the gateway. It is everything the gateway was configured to reach on an agent's behalf: internal APIs, databases, ticketing systems, whatever somebody wired into MCP because it made their assistant more useful.
That is a category worth naming plainly. When the tool-calling layer authenticates badly, the attacker does not get a shell. They get an agent's hands.
The part where we were wrong
On April 21 we published a post titled "Anthropic's MCP Has a Critical RCE Vulnerability. We Don't Use MCP. Here's Why." It was about the STDIO transport's configuration-to-command-execution path, and the argument was that we had looked at the protocol and decided not to adopt it.
We run two MCP servers now.
Our threat-intel corpus is exposed over MCP, and so is our supply-chain checker. Both are live, both are public, and anyone reading that April post and then looking at our infrastructure would find a contradiction we put there ourselves.
So let us square it, because the honest version is more useful than the tidy one. The April post was right about the specific defect and too broad in its conclusion. "This transport has a dangerous default" became "we don't use this protocol," and those are different claims. The first is a finding. The second is a posture, and we adopted the opposite posture four months later without going back and saying so.
That is the failure. Not building the servers — building them while a post carrying the old position sat published and uncorrected. Our own blog is our institutional memory. When it says something we no longer believe, and we know it, and we leave it, the memory is worse than empty.
What we actually concluded, which is what we should have written
Read our servers against this CVE and you can see what we decided rather than what we said.
Both of ours are read-only. Neither holds a customer credential. Neither fronts privileged tooling, and neither has a passthrough path, because there is no privileged thing behind them to pass through to — the corpus is public on purpose. That is why CVE-2026-59822's shape does not transfer to them: not because we were clever about auth, but because we gave them nothing worth stealing. An auth bypass against a public read-only index gets you what curl already gets you.
That is the actual position, and it is narrower and more defensible than "we don't use MCP." Expose what is already public and the auth layer is not load-bearing. The moment an MCP server holds a key, reaches a private system, or writes anything, it becomes exactly the thing LiteLLM is on the KEV list for, and the auth layer becomes the only thing standing up.
We have not audited our second server's auth path with the care this CVE deserves. It is on the list, and we will publish what we find, including if what we find is embarrassing.
The fallback pattern, which is the transferable part
Go and grep your own code for this shape. Not for LiteLLM — for the pattern.
You are looking for an authentication or authorization routine with a try/except, an or, a default parameter, or an early return that produces a valid-shaped credential when the real one could not be produced. Empty user objects. Anonymous session defaults. A catch that logs a warning and continues. Any place where the absence of an identity is represented by an object rather than by a refusal.
The reason this class survives review is that it reads as defensive programming. Somebody was making sure a transient failure in the auth backend did not take the whole service down, and that instinct is correct in most of a codebase and catastrophic in this specific function. Failing open is a legitimate design choice for a DNS lookup. It is never one for an identity check.
The tell is that the fallback constructs something instead of raising something. If the unhappy path in your authenticator ends in a constructor rather than an exception, read it again.
What to do
Upgrade LiteLLM to 1.84.0 or later. The federal deadline is September 16 and there are two public exploits, so the window between reading this and someone scanning for it is not long.
If you cannot upgrade immediately, the MCP Streamable HTTP endpoint is the exposed surface — take it off the internet until you can. Reachability is the whole vulnerability here; there is no local component.
Then go look at what your gateway's MCP tools are actually wired to. Not what you meant to expose — what is in the config file today. Every one of those is something an unauthenticated caller could reach during whatever window you were vulnerable, and the logs that would tell you whether anyone did are on the same box.
No lead claim on this one
We had no receipt on CVE-2026-59822 before disclosure. We did not pre-stage it, our harvester did not flag it, and our timestamp on the whole subject is today. Three KEV entries for one component in four months is a real pattern and we called it in June, but calling a pattern is not the same as catching a bug, and we are not going to blur those two things because the third entry made the earlier posts look good.
What we did catch, in March, was LiteLLM's poisoned package versions — six weeks before CISA listed the first CVE. That receipt is real, it is dated, and it is about a different defect entirely.
Was this useful? Rate this post — the widget is at the bottom of the page, and we read every response.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=litellm-just-took-its-third-cisa-kev-entry-this-one-is-an-mcp-auth-bypass-and-in-april-we-publish
Comments