Dating note: this CVE was published in early July, and one tracker updated its page on September 2–3. I’m writing it up now because it’s the kind of bug that sits unnoticed in a self-hosted setup, and plenty of coding-agent stacks put a gateway like LiteLLM between the agent and the models. I haven’t run an exploit or tested a deployment. Everything here comes from two public write-ups of the advisory, Lutra Security’s field guide and a CraftedSignal brief.

What the bug is

LiteLLM is an open-source proxy that exposes many model providers behind one API. It can also expose MCP (Model Context Protocol) tools through a Streamable HTTP endpoint. According to both write-ups, that endpoint had an authentication bypass in an OAuth2 “passthrough” fallback:

  • Normally, LiteLLM validates the key you send.
  • When validation failed, the fallback didn’t reject the request. It substituted an empty authentication object (UserAPIKeyAuth() in the CraftedSignal description).
  • The result: any Authorization: Bearer ... value, even a fabricated one, was treated as authenticated.

An unauthenticated caller could then reportedly reach routes such as /mcp/list_tools and /mcp/call_tool, which means listing tools and calling them, and reaching whatever services were wired in through MCP. What an attacker can actually do depends entirely on what tools your gateway exposes. A gateway with a read-only docs tool is a small problem. One with database or ticketing tools is a bigger one.

Affected and fixed versions

  • Affected: LiteLLM before 1.84.0
  • Fixed: 1.84.0

The weaknesses are listed as CWE-287 (improper authentication) and CWE-306 (missing authentication for a critical function).

The numbers disagree

This is why I’d read more than one source on any CVE:

  • Lutra lists a CVSS 4.0 score of 8.8. CraftedSignal says 8.2. I can’t tell which scoring version or vector each is using, so treat “high” as the safe summary.
  • CraftedSignal’s brief reports no confirmed in-the-wild exploitation and lists KEV as “no” in its metadata, yet its own “what’s new” note dated September 2 cites CISA’s Known Exploited Vulnerabilities catalog. Those two statements can’t both be right on the same page. If KEV status matters to your patch policy, check CISA’s catalog directly instead of trusting either aggregator.

What I’d do

  1. Upgrade to 1.84.0 or later. Lutra lists nothing else as a mitigation.
  2. If you can’t upgrade today, CraftedSignal suggests blocking or disabling the /mcp/ routes at your reverse proxy or API gateway.
  3. Look through access logs for requests to /mcp/ that carry an Authorization: Bearer header from clients you don’t recognize.
  4. Ask yourself why the MCP route is reachable from outside at all. Gateways that only agents on a private network should call don’t need a public /mcp/ path.

Why this one stuck with me

The pattern is old: a “be helpful when the real check fails” fallback that quietly becomes “let everything in.” What’s new is the blast radius. An MCP endpoint isn’t just data; it’s actions. I covered a different part of the same trust problem in the Claude Code permission fixes and a supply-chain angle in the Malfex npm campaign. Agent infrastructure is now a normal place for ordinary web-security bugs to land.

Sources: Lutra Security, CraftedSignal.