DEV Community

StarkMan
StarkMan

Posted on

Your AI Gateway Is an Identity Boundary: The LiteLLM MCP Authentication Bypass

#aisecurity #authentication #llminfrastructure #mcp

Your AI Gateway Is an Identity Boundary: The LiteLLM MCP Authentication Bypass

AI gateways arrived quietly. A team needs one endpoint that speaks to several model providers, tracks spend, and applies rate limits, so a proxy gets deployed. Within a year it holds provider API keys, routes production traffic, and sits on the network with a service account. It has become an identity boundary without anyone deciding it should be one.

The vulnerability

CVE-2026-59822 affects BerriAI LiteLLM, an open-source gateway and proxy for large language model APIs. The flaw is an improper authentication issue in the Model Context Protocol (MCP) handling, specifically in the OAuth2 fallback path. When the fallback logic executes, it substitutes an empty authentication object, and requests that should be rejected are processed as authenticated.
The practical effect is that an unauthenticated caller can reach MCP tool listings and invocation endpoints. Fixed versions begin at LiteLLM 1.84.0.
CISA added the flaw to the KEV catalog on September 2, 2026, with a federal remediation deadline of September 16. The CVSS score is 8.8.

Why an AI gateway is a high-value target

The severity of this class of flaw comes from what the gateway holds rather than what it computes.
A LiteLLM deployment typically stores credentials for every upstream model provider it brokers. Those keys carry billing authority. An attacker who reads them can run inference on the organization's account, which is a direct financial loss, and can also reach whatever the provider account is authorized to access.
The gateway also sees prompt and response traffic. Depending on the deployment, that traffic contains source code, internal documents, customer data, and system prompts that describe internal architecture. A gateway compromise is a data exposure event even when no model is manipulated.
Finally, MCP endpoints are tool-invocation surfaces. If the gateway brokers MCP servers that can execute code, query databases, or call internal APIs, then reaching those endpoints unauthenticated means reaching the tools behind them.

The pattern across the September KEV batch

LiteLLM was not alone. The September 2 KEV additions included three components that sit in AI and workflow infrastructure: LiteLLM, the Kestra workflow orchestrator, and the Starlette ASGI framework that underpins many Python model-serving stacks. Reporting on the batch noted that this was the first time AI infrastructure featured prominently in a single KEV addition.
That clustering is not a coincidence. These components share a deployment pattern: they are stood up quickly by teams under delivery pressure, they are exposed to internal networks or the internet to be useful, and they are often outside the scope of the organization's established patch process because they were adopted as tooling rather than as infrastructure.

What to do

  1. Inventory AI infrastructure explicitly. Ask engineering and data teams to produce a list of model gateways, MCP servers, vector databases, and inference proxies. Components that are not in the asset inventory will not be patched.
  2. Upgrade to a fixed release. LiteLLM 1.84.0 or later for CVE-2026-59822.
  3. Remove public exposure. A model gateway rarely needs to accept connections from the internet. Place it on an internal network and require authenticated access from the applications that use it.
  4. Rotate provider credentials. Treat any key the gateway held as potentially disclosed. Rotation should cover model provider keys, any cloud credentials reachable from the gateway, and the gateway's own administrative tokens.
  5. Review usage and billing records. Unexpected inference volume or unfamiliar model usage is a detection signal for this class of compromise.

The structural point

The security industry has spent years arguing that identity is the new perimeter. AI gateways are a concrete case where that perimeter was created by adoption rather than by design. A service that holds credentials for a dozen providers and brokers tool execution deserves the same treatment as an identity provider: patching discipline, network restriction, credential rotation, and monitoring.
Treating it as a convenience proxy is how it ends up in a KEV batch.

References

Top comments (0)