A single character was enough to authenticate to vulnerable LiteLLM gateways

A honeypot set up to impersonate a LiteLLM deployment captured an intrusion that began with a GET request to the models endpoint carrying an Authorization header containing a single character: x. According to a post on dev.to recounting the capture, the request was accepted. The incident points to a real weakness in LiteLLM, an open-source AI gateway, and to a broader pattern in which AI infrastructure has become a target for attackers mining cryptocurrency and harvesting credentials.

How the authentication flaw works

The post attributes the behaviour to CVE-2026-59822, an improper authentication vulnerability in LiteLLM's MCP Streamable HTTP endpoint. In the OAuth2 header handling path, when a token fails validation the code returns an empty authentication object rather than rejecting the request. Because that object carries no restrictions, it satisfies the authorisation check, so any bearer token — even a one-character string — is accepted.

The practical consequence is that an unauthenticated attacker can list and invoke MCP tools, which are the mechanism by which an AI gateway reaches downstream systems.

A concentration of credentials

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. As the dev.to post explains, that design concentrates value: provider API keys for every integrated vendor, virtual keys issued to applications and teams, upstream endpoint configuration and, in many deployments, database access and cloud credentials.

Research published by Wiz, cited in the post, described attackers reading the running Python process's memory to recover the LiteLLM proxy master key, which bypasses key files and configuration paths entirely. Wiz also described direct queries against LiteLLM database tables that hold model configuration and key material.

A chain, not a single bug

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 together, the post states, these produce fully unauthenticated remote code execution, and reporting has associated the chain with the Qilin ransomware group. CISA added a LiteLLM entry to its Known Exploited Vulnerabilities catalog on 2 September 2026.

What the honeypots observed

Wiz ran honeypots impersonating LiteLLM, MCP servers, LangChain, Flowise, Langflow, OpenWebUI and Node-RED over roughly 90 days, and Microsoft published independent findings over the same period. The observed behaviours were specific:

• A miner was placed in a hidden .claude directory and renamed unicorn, blending into an AI development environment.
• Persistence relied on ordinary mechanisms: modified SSH keys, altered cron entries, services renamed to look legitimate, immutable file attributes and restart-surviving hooks.
• In RAGFlow, a hidden Python hook in the LLM provider configuration path silently captured API keys, model names, provider types and endpoints each time an administrator saved settings.
• In Kestra, an authentication bypass was used to run shell commands through a workflow and mine Monero.

What operators should do

The advisory identifies LiteLLM 1.84.0 as the fixed version for CVE-2026-59822. Beyond upgrading, the post recommends inventorying AI infrastructure that never entered a security asset register, keeping MCP and administrative endpoints off the public internet, and disabling unused test routes — the command injection lived in a test endpoint.

It also advises moving secrets out of environment variables and configuration files in favour of managed secrets with short-lived credentials, since reading process memory defeats file-based protection. Operators should check for specific artifacts: unexpected entries in ~/.ssh/authorized_keys, hidden directories in AI project paths, and processes named after common system daemons.

Why it matters

The significance of CVE-2026-59822 is not that a single check was written incorrectly. It is that one 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 — one that, in this case, a one-character token was enough to cross.

The MCP test endpoint illustrates a related lesson. 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 should be treated as one rather than as a diagnostic convenience.