A Bearer Token and a Blank: How a LiteLLM Auth Bug Landed in CISA's Exploited Catalog and Made AI Gateways a Target

On September 2, 2026, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added seven vulnerabilities to its Known Exploited Vulnerabilities (KEV) catalog — the federal government’s definitive list of bugs with confirmed real-world exploitation. Six of them were the usual suspects: SonicWall appliances, a Sangoma PBX, JFrog Artifactory, an open-source workflow engine. The seventh was different. It lives not in a firewall or a router but in a piece of software that thousands of AI engineering teams run largely without a second thought: LiteLLM, the open-source LLM gateway that proxies traffic between applications and OpenAI, Anthropic, Google, and dozens of other model providers.

The flaw, CVE-2026-59822 (CVSS 8.8), is an improper-authentication bug in LiteLLM’s Model Context Protocol (MCP) Streamable HTTP endpoint. It allows an unauthenticated attacker to establish a fully authenticated MCP session using nothing more than an arbitrary Bearer token. And per Google-owned Wiz, attackers have already been observed probing LiteLLM deployments — including Wiz’s own honeypots — for model-enumeration endpoints. For federal agencies, the clock is already tight: under Binding Operational Directive 26-04, LiteLLM and Starlette flaws carry a September 16, 2026 remediation deadline, while the rest of the batch had to be patched by September 5.

The bug: when failure returns success

The technical story is almost poetic in its simplicity. LiteLLM’s MCP Streamable HTTP endpoint validates incoming Bearer tokens. In versions prior to 1.84.0, when that validation failed — when a token was obviously forged or garbage — the code path fell back to an OAuth2 passthrough mode and returned an empty authentication object instead of rejecting the request outright.

The result: a request with a fabricated Authorization header could trigger the OAuth2 passthrough fallback, and the empty auth object flowed downstream as if the caller had been verified. Unauthenticated requests reached MCP tooling without a valid LiteLLM key. Attackers could list available MCP tools, invoke them, and pivot to whatever downstream services the gateway was wired to.

The patch, shipped in LiteLLM 1.84.0, makes failed key validation fail closed. But the deeper lesson is about what the gateway is. An LLM proxy is not a simple HTTP relay. It holds provider API keys, model routing configuration, virtual keys issued to internal teams, and — increasingly, with MCP support — live tool access into databases, internal APIs, and agent workflows. A single auth bypass in that layer doesn’t expose one service. It exposes the entire AI stack behind it.

Not LiteLLM’s first KEV entry — and the exploit chains are documented

What makes this KEV addition notable is that it is not an isolated event. In June 2026, CISA added CVE-2026-42271 (CVSS 8.7), a command-injection flaw in LiteLLM, to the same catalog after evidence of active exploitation. And the two bugs are not merely neighbors in a database: according to reporting by The Hacker News, a June report from Horizon3.ai showed that CVE-2026-48710 — the Starlette request-smuggling flaw added in this same September 2 batch — could be chained with CVE-2026-42271 to bypass authentication and achieve remote code execution against vulnerable LiteLLM deployments.

Microsoft’s telemetry, published the same week, fills in what attackers actually do once inside. Threat actors breaking into LiteLLM gateways using these flaws were observed:

• Delivering an XMRig cryptocurrency miner via an ELF binary, after fingerprinting the host and killing competing mining processes
• Accessing the LiteLLM-backed PostgreSQL data tier using previously collected database information
• Targeting LiteLLM’s own tables — LiteLLM_ProxyModelTable and LiteLLM_VerificationToken — to harvest model configuration, upstream provider key material, provider endpoints, and proxy-issued virtual keys
• Adding persistence by modifying ~/.ssh/authorized_keys

Wiz separately linked the Qilin (aka Agenda) ransomware operation to active exploitation of the LiteLLM chain. This is the lifecycle of a mature attack surface: initial access, credential harvesting, cryptomining, persistence, and ransomware — all documented against the same open-source gateway.

AI infrastructure is now the target, not just the tool

The most consequential framing comes from Microsoft and Wiz jointly: LiteLLM, Flowise, LangChain, Langflow, ChromaDB, Ollama, Marimo, and MCP servers have become “lucrative targets” for stealing API keys, accessing backend systems, maintaining persistence, running prompt injections, and mining cryptocurrency.

AI Weekly’s analysis of the September 2 batch made a structural observation worth repeating: this was the first KEV cohort where AI infrastructure accounted for nearly half the entries. And the exposure problem is subtler than “unpatched servers.” Starlette, for instance, rarely appears in anyone’s asset registry directly — it arrives as a transitive dependency under FastAPI, meaning procurement-based inventories simply don’t see it. Meanwhile, patches for all three AI-related CVEs in the batch had been available 56 to 99 days before cataloging, with no vendor telemetry or research attribution accompanying them. Teams were not ignoring patches; the patches were invisible to them because the software itself was invisible.

There is also an uncomfortable timing contrast. The LiteLLM bug sat in the wild through a summer in which the industry’s security discourse was dominated by frontier-model incidents — rogue agent swarms, sandbox escapes, the Hugging Face breach. Those stories matter. But the September 2 KEV batch is a reminder that the most operationally exploited AI vulnerabilities of 2026 are not exotic agent misalignment cases; they are boring, decade-old vulnerability classes — improper authentication, command injection, request smuggling — landing in the new infrastructure everyone installed in a hurry.

What to do now

For anyone running LiteLLM in any capacity, the checklist is short and unforgiving:

1. Upgrade to LiteLLM 1.84.0 or later immediately. This closes CVE-2026-59822. If you cannot upgrade, disable the MCP Streamable HTTP endpoint until you can.
2. Rotate every credential the gateway can see. The documented attack path harvests upstream provider keys and virtual keys from the database tier. Treat any pre-patch exposure as a potential key disclosure — rotate provider API keys, virtual keys, and database credentials.
3. Audit for persistence. Check authorized_keys, cron entries, and running processes for unexpected miners or shells — the documented follow-on actions are specific and detectable.
4. Inventory your transitive dependencies. If you run FastAPI anywhere in your AI stack, you probably run Starlette. Check whether CVE-2026-48710 applies to you, even if you never chose to install Starlette directly.
5. Assume the AI gateway is production-critical infrastructure. It holds the keys to every model your organization uses. It deserves the same patch SLAs, network segmentation, and monitoring as your database layer.

Federal civilian agencies have no choice in the matter — BOD 26-04 deadlines are binding. Everyone else should treat September 16 as their deadline too. The honeypot evidence is already in: attackers are enumerating LiteLLM endpoints right now, looking for gateways that never got the memo.