Table of contents
16
Deep Analysis by Salman Khan, OSCP+, Founder of XHack, SRT (Synack Red Team member)
Read this in 30 seconds: CVE-2026-59822 is an authentication bypass in LiteLLM, the AI gateway thousands of teams put in front of their LLM APIs, and it takes exactly one character to exploit.
- The “password” that gets you in is a single letter. Send
Authorization: Bearer xto the wrong endpoint and LiteLLM treats you as authenticated. No key, no account, nothing to guess.- CISA calls it the first MCP flaw ever added to its exploited-vulnerabilities list. Not the first LiteLLM bug. The first Model Context Protocol vulnerability of any kind on that list.
- The deadline already passed. CISA gave federal agencies until September 16, 2026 to patch. That was six days ago.
- Wiz caught it happening for real. Their honeypots logged live attackers sending single-character bearer tokens at the model-listing endpoint, not a lab demo.
- The fix has existed since July. LiteLLM 1.84.0 closed this in the same month the bug was privately disclosed. Anyone still exploited by September was running a two-month-old, already-patched hole.
Most authentication bypasses need cleverness. This one needed a typo that nobody caught.
CVE-2026-59822 lives in LiteLLM, the open-source proxy that sits between an application and every LLM API it calls, OpenAI, Anthropic, Azure, a self-hosted model, whatever the team is using that week. LiteLLM’s job is to be the one door everything goes through. That is also exactly why an authentication bug in it is not a small bug.
The short version: a request with a made-up bearer token, sent to the right endpoint, does not get rejected. It gets treated as valid. Here is what that means, how it happened, and what to check on your own LiteLLM instance today.
Skip this section if you already run LiteLLM. For everyone else: LiteLLM is one of the most widely deployed AI gateways, a proxy server that stands in front of one or more LLM providers and gives every application in a company a single, consistent API to call, regardless of which model is actually answering behind it. Teams like it because it centralizes billing, rate limits, logging, and access control for every LLM call in the organization, instead of scattering raw API keys across a dozen services.
More recently, LiteLLM added support for the Model Context Protocol (MCP), the open standard, originally from Anthropic, that lets an AI application connect to external tools and data sources through a common interface. Think of MCP as the wiring that lets an AI agent actually do things: query a database, call an internal API, write to a ticketing system, instead of just generating text. LiteLLM’s MCP support means the gateway is not just relaying chat completions anymore. It is a relay point for whatever tools an organization has wired an AI agent to use.
That combination, one proxy, holding every upstream API key, now also routing tool calls, is what makes CVE-2026-59822 worth thirty minutes of your attention even if you have never heard of LiteLLM before today.
Here is the vulnerability description, straight from the GitHub Security Advisory LiteLLM’s own maintainers published, and matched verbatim in NVD’s record:
“LiteLLM’s MCP Streamable HTTP endpoint allowed an unauthenticated attacker to use a fabricated Authorization header to trigger an OAuth2 passthrough fallback path that replaced failed LiteLLM key validation with an empty
UserAPIKeyAuth()object, allowing requests to reach MCP tooling without a valid LiteLLM key.”
Translate that out of advisory-speak and the bug is almost funny, in the way security bugs sometimes are right before they are not:
Authorization: Bearer <token> header.UserAPIKeyAuth() object and hands the request through as if it had authenticated successfully.An empty object that means “authenticated” is the whole vulnerability. It does not matter what the bearer token actually says, because nothing downstream ever checks it again. Wiz’s honeypot research put it as plainly as it gets: “Any Bearer token (even just a single character, e.g., x) grants full MCP access.”
They caught it happening. Their telemetry shows real attackers sending exactly this:
GET /v1/models HTTP/1.1
Authorization: Bearer xOne character. Full access to whatever MCP tools that LiteLLM instance exposes.
CVE-2026-59822 carries two different CVSS scores, and both are correct, they just come from different scoring systems:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N.CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N.Both vectors agree on the shape of the risk, which is the part that matters: reachable over the network (AV:N), no special conditions required (AC:L), no privileges needed (PR:N), and no user has to click anything (UI:N). The two systems weigh the confidentiality impact slightly differently, which is the whole reason the number moves. Either way, this is a high-severity, pre-authentication bug.
CISA’s own catalog entry classifies CVE-2026-59822 under two weakness types: CWE-287 (Improper Authentication) and CWE-306 (Missing Authentication for Critical Function). That second one is the more honest description. This was not a clever bypass of a strong check. It was a critical function with no working check behind it at all.
CISA added CVE-2026-59822 to its Known Exploited Vulnerabilities (KEV) catalog on September 2, 2026, with a required remediation date of September 16, 2026 for federal agencies. That deadline is six days behind us as of this writing.
The KEV catalog only takes vulnerabilities CISA has evidence are being exploited right now, not theoretical risks. For a CVE, getting listed at all is a signal. Getting listed as the debut entry for an entire category of software is a bigger one: outlets covering the addition, including Forkast News, noted that this is the first Model Context Protocol vulnerability CISA has ever added to KEV. Not the first LiteLLM bug. The first MCP bug, period, across every vendor building on the protocol.
That matters beyond the headline. MCP adoption has moved fast in 2026, and most of the security tooling built around it is still young. CVE-2026-59822 is a preview of the category: authentication logic written for one flow (human OAuth login) quietly reused for a completely different one (machine-to-tool access), with a fallback path nobody stress-tested against a forged header.
CVE-2026-59822 is not an information leak. It is a working session inside your AI gateway, and what that session can reach depends entirely on what your organization has connected.
MCP exists specifically to let an AI agent take actions through tools: run a database query, call an internal API, trigger a workflow, read a file store. LiteLLM’s own advisory describes the impact as the ability to “list and call configured MCP tools and access connected services exposed through MCP.” Whatever your AI stack was allowed to touch, an attacker holding a forged one-character token can now ask it to touch too.
That blast radius is organization-specific, which is exactly what makes it dangerous to guess at from the outside. A LiteLLM instance wired only to a read-only documentation search tool is a very different exposure than one wired to a database-write tool, a deployment pipeline, or a ticketing system with a refund action attached. The vulnerability does not care which one you built. It hands over whichever one is there.
Worth being precise about what CVE-2026-59822 is not, too. A separate LiteLLM issue, CVE-2026-59821, covers a post-authentication remote code execution flaw through custom code guardrails, a different bug entirely, and LiteLLM has also been hit through an unrelated Starlette request-smuggling flaw (CVE-2026-48710) that Wiz has tied to a Qilin ransomware crew dropping cryptocurrency miners on exploited hosts. Those are real, but they are not CVE-2026-59822. Keep the bugs straight when you are deciding what to patch and in what order, because they have different fixes.
Two questions decide it:
1. What version of LiteLLM are you running? Anything before 1.84.0 is vulnerable. Check it directly:
pip show litellm | grep Version
# or, for a running proxy:
curl -s https://your-litellm-host/health/readiness2. Is MCP enabled, and is the proxy reachable from outside a trusted network? If MCP routes are active and the /mcp/ path is reachable by anything other than internal, authenticated traffic, you are exposed exactly the way Wiz’s honeypots were.
A related, uncomfortable data point: earlier research into public LiteLLM deployments found that roughly 1 in 10 internet-facing instances still accept the default master key, sk-1234, or require no authentication at all. That default ships in LiteLLM’s own quickstart documentation, which is convenient for a five-minute demo and a real liability if it is still the production key months later. CVE-2026-59822 does not need that default key to work, but if your deployment also has it, you have two open doors instead of one.
/mcp/ from outside your trusted network removes the reachable attack surface until you can update.sk-1234 is not a secret anyone should still be relying on. Generate a real one and store it the way you would any other production credential.For the wider pattern behind CVE-2026-59822, not just this one bug, our MCP server security guide covers the attack surface MCP opens up more broadly, tool-description injection included, and why most teams have not actually tested it yet.
Short, because this is a news piece about CVE-2026-59822, and it is a reminder that the fastest-growing part of most companies’ attack surface right now is the AI infrastructure wired in over the last year, gateways, agents, and the tools they can now reach through protocols like MCP, most of which nobody has pointed a real test at yet. That is exactly the gap our AI agent and human testers are built to close: finding the exposed proxy, the default key nobody rotated, the tool connection nobody scoped, before an attacker sending a one-character token finds it first. Your data stays on your own machine while we do it.
CVE-2026-59822 is an authentication bypass in LiteLLM, an open-source AI gateway, affecting versions before 1.84.0. A flaw in how the MCP Streamable HTTP endpoint handled failed authentication let an attacker send a fabricated bearer token and be treated as authenticated, reaching MCP tools and connected services without a valid API key.
Yes. CISA added it to the Known Exploited Vulnerabilities catalog on September 2, 2026, based on evidence of active exploitation, and Wiz’s honeypot research independently captured live attackers sending single-character bearer tokens to probe model-listing endpoints.
CVE-2026-59822 is the first vulnerability specific to the Model Context Protocol that CISA has added to its Known Exploited Vulnerabilities catalog, across any vendor building on MCP, not just LiteLLM. It marks MCP infrastructure as a category CISA is now watching for active exploitation.
Upgrade LiteLLM to version 1.84.0 or later, which closes the vulnerable fallback path entirely. If an immediate upgrade is not possible, block the /mcp/ routes at your reverse proxy or gateway as a temporary measure, and rotate your master key if it was ever left at the default sk-1234.
Whatever your organization has connected through MCP. LiteLLM’s advisory describes the impact as the ability to list and call configured MCP tools and access the services those tools reach, which could mean anything from read-only lookups to database writes, deployment actions, or other connected services, depending entirely on your own setup.
No. Those attacks used a different flaw, a Starlette request-smuggling vulnerability (CVE-2026-48710) chained with another bug, and have been tied by Wiz to a Qilin ransomware crew. CVE-2026-59822 is a separate authentication bypass in LiteLLM’s own MCP endpoint. Both are real, but they need different fixes.
CVE-2026-59822 did not need a clever exploit chain, a race condition, or months of fuzzing to find. It needed one authentication path that fell back to “trust it anyway” instead of “reject it,” and a bearer token short enough to type with one finger. The fix has existed since July. The active exploitation of CVE-2026-59822 started before most teams had applied it, and CISA’s own deadline for federal systems has already come and gone.
If you run LiteLLM, or anything else sitting in front of your AI infrastructure with a fallback path you have never actually tested, this is the week to go check it, not the week to assume someone else already did.
Categories
Related articles
