A One-Character Token Was Enough: LiteLLM and the Credential Concentration Problem in AI Gateways A one-character bearer token was enough to bypass authentication in LiteLLM's MCP Streamable HTTP endpoint, tracked as CVE-2026-59822, because the OAuth2 header path returned an empty authentication object instead of rejecting failed tokens. Chained with a command injection in the MCP stdio test endpoint (CVE-2026-42271) and a Starlette host header bypass (CVE-2026-48710), the flaws yield fully unauthenticated remote code execution, with reporting tying the chain to the Qilin ransomware group. Wiz honeypots impersonating LiteLLM, MCP servers, LangChain, Flowise, Langflow, OpenWebUI and Node-RED over roughly 90 days observed attackers reading proxy process memory for the master key and querying database tables holding model configuration and key material. In one honeypot capture, the request that started an intrusion looked like this: a GET to the models endpoint with an Authorization header containing the single character x . It worked. That detail is the clearest possible illustration of what went wrong in LiteLLM, and of why AI gateways have become a category of infrastructure that deserves the same scrutiny as an identity provider. CVE-2026-59822 is an improper authentication vulnerability in LiteLLM's MCP Streamable HTTP endpoint. The root cause is in the OAuth2 header handling path: when a token fails validation, the code returns an empty authentication object rather than rejecting the request. An object with no restrictions satisfies the check. Any bearer token, including a single character, passes. The practical effect is that an unauthenticated attacker can list and invoke MCP tools. Those tools are not decorative. They are the mechanism by which an AI gateway reaches downstream systems. LiteLLM is a proxy that fronts many model providers. Organisations deploy it so that applications can call multiple models through one interface, with centralised key management, cost tracking and access control. That design concentrates value: Research published by Wiz described attackers reading the running Python process memory to recover the LiteLLM proxy master key, which bypasses key files and configuration paths entirely. They also described direct queries against the LiteLLM database tables that hold model configuration and key material. CVE-2026-59822 was not exploited alone. Two related issues complete the picture. CVE-2026-42271 is a command injection in the MCP stdio test endpoint: an attacker submits a forged MCP server configuration whose command field launches a Python downloader and a miner, while the test still returns a normal-looking handshake. CVE-2026-48710 is a host header bypass in Starlette, the underlying ASGI framework, which allows path injection that defeats authentication checks depending on the reconstructed URL. Chained, these produce fully unauthenticated remote code execution. Reporting associated the chain with the Qilin ransomware group. Wiz ran honeypots impersonating LiteLLM, MCP servers, LangChain, Flowise, Langflow, OpenWebUI and Node-RED over roughly 90 days. Microsoft published independent findings over the same period. The observed behaviours are worth listing because they are specific: .claude directory and renamed unicorn , blending into an AI development environment. ~/.ssh/authorized keys , hidden directories in AI project paths, and processes named after common system daemons that hold real memory. The reason CVE-2026-59822 matters is not that a check was written incorrectly. It is that a single component had accumulated access to every model provider, every application key, the database and, in many deployments, the cloud environment. When a component aggregates that much authority, its authentication logic stops being an implementation detail and becomes a control boundary. The MCP test endpoint illustrates a related point. A feature whose purpose is to verify that a configuration works must execute the command in that configuration. That is the design. It also means the endpoint is, by construction, an execution surface, and it should be treated as one rather than as a diagnostic convenience.