LiteLLM is the plumbing a large number of AI products quietly run on: a proxy that sits in front of dozens of model providers and gives applications one consistent API to call them through, including the Model Context Protocol (MCP) interface that lets a model invoke external tools. In August 2026, BerriAI, the company behind LiteLLM, fixed a bug in that proxy’s authentication code that let anyone reach the tool-calling endpoint without a valid key at all. CISA added it to its Known Exploited Vulnerabilities catalog on 2 September, meaning this wasn’t a theoretical bypass — someone was already using it.

A fallback path that trusted the thing it was supposed to check

The flaw, tracked as CVE-2026-59822 and rated CVSS 8.8 in BerriAI’s own GitHub Security Advisory, sits in the authentication handler for LiteLLM’s MCP Streamable HTTP endpoint. That handler has two ways to authenticate an incoming request: LiteLLM’s own API key check, and a secondary “OAuth2 passthrough” path meant for cases where the request is actually authenticated upstream, by whatever MCP server LiteLLM is proxying to.

The bug is in what happened when the primary check failed. According to the advisory, a failed LiteLLM key validation didn’t reject the request — it fell back to constructing an empty UserAPIKeyAuth() object and let the request through anyway. An attacker who sent a request with a completely fabricated Authorization header — a bearer token that matched nothing, validated against nothing — triggered exactly that fallback. The system’s response to “I couldn’t verify who this is” was to proceed as if verification were beside the point. Anyone able to reach the endpoint could list and invoke whatever MCP tools the deployment had configured, and reach whatever backend services those tools were wired up to, without possessing a LiteLLM API key at any point in the request.

Why this matters more on an AI gateway than it would elsewhere

An MCP-connected LiteLLM deployment is typically wired to more than just model providers — MCP tools are how a model reads a company wiki, queries a database, or triggers an action in another system. An authentication bypass on that specific endpoint doesn’t just leak API usage; it hands an unauthenticated caller the same tool-invocation surface the organization built for its own trusted AI agents. The credited reporter, a GitHub user going by yaaras, disclosed the bug through BerriAI’s standard advisory process; BerriAI fixed it in version 1.84.0 and, per the same advisory, recommended that anyone unable to upgrade immediately block or disable MCP routes at the reverse-proxy layer as a stopgap — an acknowledgment that the in-application fix alone wasn’t fast enough for every affected deployment to reach in time.

This is the second time in 2026 that a LiteLLM authentication flaw has drawn active-exploitation attention: an earlier pre-auth SQL injection bug in the same product was reported under active exploitation by The Hacker News just months before CVE-2026-59822 surfaced, and BerriAI’s own April 2026 security post disclosed a separate authentication-cache bypass fixed in version 1.83.0. None of these are the same bug recurring — they’re different authentication paths in the same growing piece of infrastructure, each found and fixed in turn. That pattern is less a knock on LiteLLM specifically than a preview of what’s coming for the whole category: AI gateways are new enough, and being extended fast enough, that their authentication surface is still being discovered by attackers and defenders at roughly the same pace.

The lessons that generalise

A fallback path is a second authentication system, and it needs the same scrutiny as the first one. The OAuth2 passthrough fallback existed for a legitimate reason — supporting upstream-authenticated MCP servers — but “legitimate reason for the path to exist” and “safe default when the primary check fails” are different design questions. Any code that reacts to “validation failed” by constructing a default object instead of raising an error should be read as a potential bypass until proven otherwise.

“Empty” is not the same as “unauthenticated,” and treating it as equivalent is where bypasses live. UserAPIKeyAuth() with no fields populated is not nothing — it’s a valid-looking session object that downstream code will happily accept as legitimate. The fix wasn’t to make the empty object safer; it was to stop issuing it on a failed check at all.

New protocol surfaces inherit old vulnerability classes, they don’t invent new ones. MCP is a new specification, but CVE-2026-59822 is a textbook fail-open authentication bug — the same shape of mistake that shows up in web frameworks, VPN appliances and artifact repositories. Teams standing up MCP endpoints fast, to keep pace with how quickly the protocol is being adopted, are exposed to exactly the same review gaps that hit any authentication code shipped under time pressure.

AI infrastructure is now infrastructure, full stop, and belongs in the same patch-and-monitor discipline as anything else internet-facing. CISA didn’t create a special, lighter-weight category for an AI gateway bug — it went into the same Known Exploited Vulnerabilities catalog as a VPN appliance and an artifact repository flaw disclosed the same week. Any organization treating its LLM gateway as lower-stakes than its other edge services is drawing a distinction attackers aren’t respecting.

Tech-Bee is an independent technology publication. This piece is drawn from BerriAI’s GitHub Security Advisory for CVE-2026-59822, the GitLab Advisory Database entry for the same vulnerability, and CISA’s Known Exploited Vulnerabilities catalog.