Failing the key check was enough to get in

The sentence that made me stop is in the vendor advisory, and it describes a fallback rather than an attack. When LiteLLM could not validate a caller’s key on its MCP endpoint, the failure path replaced that failed validation with an empty authentication object [1].

Empty, but present. Downstream code got something shaped like a caller, so it carried on and served the request.

That is the whole vulnerability. Not a parser bug, not a memory corruption. A piece of error handling that answered “this key is not valid” with an object instead of a refusal, on the endpoint that fronts your agent’s tools.

What happened

CVE-2026-59822 affects LiteLLM, an open source proxy that sits between your applications and LLM providers and presents them all in one API format [2]. Its MCP Gateway feature does the same job for Model Context Protocol servers: register several of them, and LiteLLM gives you one endpoint for all their tools, with permissions managed per key, team or organisation [4].

Prior to version 1.84.0, the MCP Streamable HTTP endpoint accepted a fabricated Authorization header, which sent it down an OAuth2 passthrough path intended for authenticating to upstream MCP servers. On that path, failed LiteLLM key validation was replaced with an empty UserAPIKeyAuth() object, and requests reached MCP tooling without a valid LiteLLM key [1][2]. GitHub’s advisory states the impact directly: an attacker could list and invoke the configured MCP tools and reach the services exposed through them [1].

The timeline is the part I did not expect. The advisory published on June 30, 2026, NVD followed on July 8, and CISA added it to the Known Exploited Vulnerabilities catalog on September 2, 2026 with a remediation date of September 16 [1][2][3]. Two months between a public patch and confirmed exploitation is a long quiet period for a network reachable authentication bypass.

It arrived in company. Seven CVEs went into KEV that day, and four are developer or AI infrastructure rather than perimeter equipment: LiteLLM, the Starlette ASGI framework, Kestra, and JFrog Artifactory, alongside two SonicWall SMA1000 entries and a Sangoma Switchvox flaw [3].

Why this matters

The gateway exists to hold credentials, which is exactly what makes it worth attacking. LiteLLM’s documentation describes registering MCP servers for GitHub, Zapier, CircleCI, internal APIs generated from OpenAPI specifications, and AWS services authenticated with SigV4 [4]. The gateway holds the credential for each of those so individual callers do not have to. Reach the gateway without a key and you do not need those credentials either, because it will use them for you.

MCP tools are actions, not documents. The protocol connects AI applications to data sources, tools and workflows so they can access information and perform tasks [5]. An authentication bypass on a data API exposes records. An authentication bypass on a tool endpoint exposes whatever those tools do.

The reach is wide, though nobody has published how wide. PyPI recorded about 19.2 million downloads of litellm in the last week [7]. Downloads count automated builds and mirrors, and I have no figure for how many deployments enable the MCP gateway at all, so read that as circulation rather than exposure.

Technical breakdown

Authentication has two possible answers and this code found a third.

Two separate ideas meet on this endpoint. Inbound, a caller presents a LiteLLM key and either proceeds with that key’s permissions or is rejected. Outbound, LiteLLM authenticates to the MCP servers it fronts using whatever each one expects, including OAuth 2.0, SigV4, bearer and basic auth [4].

The flaw sits at the join. A header LiteLLM could not validate as one of its own keys sent the request onto the OAuth2 passthrough path, and that path handled the validation failure by substituting an empty authentication object rather than returning a rejection [1][2]. NVD classifies it as CWE-287, improper authentication, with CWE-306, missing authentication for a critical function [2].

An empty object is a defensible thing to construct. It becomes a vulnerability the moment a later check asks whether a caller exists rather than which caller it is.

The scores agree for once. NVD assigns 8.2 under CVSS 3.1 and GitHub, as the assigning authority, assigns 8.8 under CVSS 4.0, both HIGH, both recording high confidentiality impact with low integrity impact [2]. That fits reaching tools rather than rewriting the gateway. EPSS sits at 0.87 percent, the 56th percentile, as of September 4, 2026 [6].

The three breaks are the three places this stops. Network position removes the attacker’s reach, the upgrade removes the fallback, and least privilege on each registered server decides how much the bypass is worth once someone has it.

What defenders should do Monday morning

Immediate, within 24 hours. Find your LiteLLM version and whether the MCP gateway is enabled with servers registered. Below 1.84.0, upgrade [1]. If you cannot upgrade today, restrict the /mcp/ endpoints at your reverse proxy, which is the vendor’s own interim control [1]. Confirm those endpoints are not reachable from anywhere you did not intend, and note that the REST tool endpoints work from a plain HTTP client with no model involved [4].

Near term, this week. Review every registered MCP server and the credential the gateway holds for it. Ask what an unauthenticated caller could have done with each one, and let the answer push you toward narrower upstream scopes. Turn on LiteLLM’s per key, team and organisation permissions if you are running a single shared key [4]. Log MCP tool invocations with the calling key attached, so an unattributed call reads as an anomaly rather than as traffic.

Structural, this quarter. Go looking for other places where an authentication failure produces a default object instead of a refusal. Fallback paths between two auth schemes are where this lives, because the second scheme is usually written by someone thinking about connectivity rather than denial. Then decide deliberately whether an AI gateway belongs anywhere outside your service boundary can reach.

Checklist

• LiteLLM version identified on every deployment, and anything below 1.84.0 upgraded
• MCP gateway status known: enabled or not, and which servers are registered
• /mcp/ endpoints restricted at the reverse proxy where upgrading is not immediate
• Reachability of MCP endpoints from untrusted networks confirmed rather than assumed
• Upstream credential for each registered MCP server reviewed and scoped down
• Per key, team or organisation permissions in use instead of one shared key
• MCP tool invocations logged with calling key or team attribution
• Alerting in place for MCP requests from outside the service network
• Remediation completed against the September 16, 2026 KEV date

The failure mode is the fallback, not the protocol

There is a version of this story that blames MCP, and it would be the wrong lesson. Nothing in the protocol failed. A tool endpoint did what tool endpoints do, for a caller the gateway had already decided was legitimate.

The failure is much older than agents. Authentication code often has three outcomes rather than two: valid, invalid, and a fallback written for a different scheme that returns something empty and truthy on the way past. Nobody sits down to allow unauthenticated access to their agent’s tools. They write a passthrough for upstream OAuth, handle the failure case so the request does not crash, and construct a blank object because a blank object is what the type signature wants.

So the thing worth taking from this is smaller than a position on AI security. Go and read your own error paths in authentication code and check what each one returns. Anywhere the answer is an object rather than a refusal, find out what the next function does with it. That review costs an afternoon and does not require anyone to publish a CVE first.