A Single-Character Bearer Token Was Enough to Reach LiteLLM's MCP Gateway

Ask a platform team why their Model Context Protocol gateway does not need its own threat model and you will hear some version of the same three assumptions: it sits behind the LLM proxy, whoever reaches it already authenticated somewhere upstream, and nobody scans the internet for MCP servers anyway. CVE-2026-59822 takes those three assumptions apart at once. On LiteLLM's MCP Streamable HTTP endpoint, a Bearer token that failed every validation check still produced a working session - and Wiz's own honeypot network recorded real attackers finding that gap and using it in the same week CISA added the CVE to the Known Exploited Vulnerabilities catalog.

The mechanism is not an edge case in some rarely-used feature. LiteLLM is the open-source gateway a large share of the industry puts in front of OpenAI, Anthropic, and self-hosted model endpoints to get one API, one key-management layer, and one place to enforce rate limits and spend caps. Over the past year it has also become the default place organizations wire up MCP, the protocol that lets an LLM call real tools - databases, ticketing systems, internal APIs, file stores. If your MCP tools touch anything that matters, an authentication bypass on the gateway in front of them is not a dev-tooling bug. It is a direct line to whatever those tools are allowed to do.

Who this affects: anyone running a self-hosted LiteLLM proxy below version 1.84.0 with MCP routes enabled, whether that is a homegrown AI assistant, an internal agent platform, or a vendor product built on top of LiteLLM. If you do not run LiteLLM, or you run it purely as a model router with no MCP servers configured, the specific patch and hunt below do not apply to you - but the underlying failure mode (a rejected credential silently becoming an empty, unrestricted session object instead of a hard denial) is worth five minutes checking against any other AI gateway or MCP server in your stack, because it is a pattern, not a one-off.

The myth: MCP servers are internal, so a broken check does not matter

The reasoning usually goes that MCP traffic stays inside the perimeter, so even a soft authentication check is a defense-in-depth nicety rather than a hard requirement. BerriAI's own security advisory describes what actually shipped: the MCP auth handler supports OAuth2 passthrough for upstream MCP servers, and when that token validation failed, the fallback path did not reject the request. It replaced the failed check with an empty UserAPIKeyAuth() object - a session with no key, no scope restrictions, and no owner. Any request carrying a fabricated Authorization header reached MCP tooling as if it had passed. GitLab's advisory database puts this at CVSS 8.2 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N) - network-reachable, no privileges required, no user interaction, high confidentiality impact. That is the profile of a bug that gets found by automated scanning within days of disclosure, not a theoretical internal-network risk.

The reality Wiz measured is sharper than the CVSS score implies. A rejected credential is supposed to be a dead end. Here it was a fork in the road that quietly routed to "let them in anyway" - and the people testing that fork were not internal developers.

What Wiz's honeypots actually recorded

Wiz Research ran honeypots for 90 days across the AI-infrastructure stack most organizations are now assembling without a second thought: LiteLLM, MCP servers, LangChain, Flowise, Langflow, OpenWebUI, Node-RED, ChromaDB, and Ollama. The resulting research is the clearest public evidence that this class of software is already being hunted, not just theorized about.

Against the LiteLLM MCP endpoint specifically, Wiz observed requests carrying Bearer tokens as short as a single character - the literal letter x - successfully reaching MCP tooling and probing model-enumeration routes. That is the empty-auth-object fallback working exactly as coded, just not for anyone LiteLLM's operators intended. Three other patterns from the same research matter as much as the headline CVE:

• Chained remote code execution. A separate command-injection flaw in LiteLLM's MCP server test endpoints, CVE-2026-42271, let attackers inject Python that downloaded and ran a cryptominer from a hardcoded external host - Wiz's telemetry shows the auth bypass and the injection bug being used together, not as isolated incidents.
• Blind prompt injection with DNS callbacks. Attackers embedded instructions designed to trigger shell execution through the model, then used DNS lookups to attacker-controlled domains to confirm the command ran - a technique built specifically to work when the attacker cannot see command output directly.
• In-memory credential theft. Post-compromise, attackers queried the running Python process state directly - effectively asking the interpreter to print its own loaded API keys - rather than searching disk for a .env file. If your incident-response playbook only checks the filesystem for exposed secrets after a compromise like this, it is checking the wrong place.

The batch this landed in, and why the clock is already tight

CVE-2026-59822 was one of seven vulnerabilities CISA added to KEV on September 2, 2026, alongside flaws in Sangoma Switchvox, Kestra OSS, JFrog Artifactory, and a pair in SonicWall's SMA1000 appliances. Two of the seven - this one and CVE-2026-48710, a Starlette HTTP request-smuggling bug we covered when it first surfaced as BadHost - carry a federal remediation deadline of September 16 under BOD 26-04. The other five in the same batch had a September 5 deadline, which means as of this writing it has already passed for most of the batch. Wiz's research also documents that CVE-2026-48710 chains with CVE-2026-42271 into a fully unauthenticated remote-code-execution path when both are present unpatched - the same host header confusion we wrote about in May turns out to be a second door into the same building, not a standalone footnote from an earlier advisory.

None of this required a nation-state operator or a novel technique. It required a fallback branch that someone wrote to be permissive during development and never tightened before shipping, plus enough MCP adoption in the wild that scanning for it became worth an attacker's time. That combination is going to keep recurring across the AI-tooling ecosystem for the next several years, and LiteLLM will not be the last gateway it happens to. A three-person MSP running a self-hosted LiteLLM instance to route client-facing chatbot traffic carries the same exposure as a well-staffed platform team running the identical version; the CVE does not check headcount before it fires, and neither did Wiz's honeypot traffic.

Patch, then confirm nobody already used the gap

The fix is version 1.84.0, which replaces the fallback with a hard rejection instead of an empty auth object. Patching alone is not enough given how long this fallback has existed and how quickly Wiz caught active probing - treat every unpatched day as a day someone may have already been inside.

# 1. Confirm your running version
pip show litellm | grep -i "^Version"
# or, if running the proxy container:
docker exec <litellm_container> litellm --version

# 2. If below 1.84.0, patch first, then hunt before you close the ticket.
pip install --upgrade "litellm>=1.84.0"

# 3. Hunt your reverse-proxy / ingress logs for the exploitation pattern:
# extremely short or malformed Authorization headers hitting MCP routes.
grep -E "POST /mcp" /var/log/nginx/access.log | \
  grep -oE 'Authorization: Bearer [^"]*' | \
  awk '{print length($3), $0}' | sort -n | head -30

# 4. Cross-check against LiteLLM's own request logs (if enabled) for MCP
# tool-list or tool-call events with no matching valid key in your key store.
curl -s http://localhost:4000/mcp/tools/list \
  -H "Authorization: Bearer x" -o /tmp/mcp_probe_test.json
cat /tmp/mcp_probe_test.json   # non-empty tool list on a patched build = still exposed

If step 3 turns up short or malformed tokens against MCP routes before your patch date, do not treat this as a clean bill of health once you upgrade. Pull the list of MCP tools your gateway exposes, check what each one is scoped to reach, and rotate any credential those tools could have touched - the same in-memory-introspection technique Wiz documented means a disk-only secrets scan will tell you nothing useful. If your MCP configuration wires up a database connector, a ticketing-system integration, or an internal file-access tool, treat those specific credentials as compromised until you can prove otherwise from the logs, not from the patch date alone.

Read the tool-call logs from before the patch, not just after

The fastest way to lose this one is to treat it as "just another dependency bump" and move on once the version number changes. A gateway that fails open on a broken auth check has, by definition, been reachable by anyone who tried since the day that fallback shipped - not since the day Wiz published its research. The window that matters for your incident review starts at your original LiteLLM deployment date, not at today's upgrade. Pull whoever owns the agent platform built on top of this gateway into that review before you close the ticket; they are the only person who can tell you what each configured MCP tool was actually allowed to reach, and that scope, not the CVSS score, is what determines whether this was a near-miss or a breach.