Build1 publisher2 min readPublished
A low-privilege LiteLLM key could run system commands through its MCP test endpoints
LiteLLM's MCP test endpoints let any valid proxy key run arbitrary commands on the gateway, rated CVSS 8.8. CISA added the flaw to its Known Exploited Vulnerabilities catalog on June 8, 2026, confirming exploitation in the wild.
The Engineer · Build desk
What happened
- The endpoints ran no role check, so a virtual key scoped to one model with a small budget reached them with exactly the access an administrator key had.
- For the stdio transport the gateway handed the caller's command, arguments and environment to subprocess, with no allowlist on the command field.
- LiteLLM shipped the test endpoints in 1.74.2 and fixed the flaw in 1.83.7, leaving every release in between exposed.
- The documented campaign chained it with CVE-2026-59822, a single-character Bearer token that bypasses authentication, and CVE-2026-48710, a Starlette request-smuggling bug, to reach unauthenticated remote code execution.
- Attackers submitted forged MCP configurations that launched a Python downloader and a miner, then read the memory of running Python processes to recover the proxy master key.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- exposure A proxy that fronts OpenAI, Anthropic and local models concentrates every credential and route in one process, so running a command there reaches all of them.
- constraint Even after the patch, a PROXY_ADMIN key can still launch any of seven allowed binaries, so the fix narrows the execution surface without closing it for administrators.
- decision Because independent testing found the published version range does not match observed behaviour across every build, operators have to confirm the binary they are running, not just read the version string.
An MCP server configuration for stdio has to carry an executable, its arguments and its environment, because starting the server is a call to exec(command, args, env) [2]. The protocol does not say who may supply that command; the gateway implementer decides [3]. LiteLLM added the two test endpoints, /mcp-rest/test/connection and /mcp-rest/test/tools/list, so an administrator could preview a connection before saving it [1].
The result is that a caller holding any valid proxy key can run arbitrary commands with the privileges of the proxy process [6]. In the official Docker images that process is root, so it is command execution as root on the gateway host [10].
Send id as the command and the endpoint returns HTTP 200 with a body reporting that the connection to the MCP server failed [11]. That failure is genuine: id does not speak the MCP JSON-RPC handshake, so the backend aborts [11]. The process has already run, because spawning happens before the handshake completes; the evidence of execution is a side effect (a written file, an outbound connection, a callback), not the response body [12]. Log review keyed to error responses sees a failed test and nothing else [12].
The fix in 1.83.7 addresses both mistakes [13]. It requires the PROXY_ADMIN role on both endpoints and adds a validate_transport_fields() check that allowlists the stdio command field to npx, uvx, python, python3, node, docker and deno [13].
What to watch
- Confirmation of the exact patched builds if the published version range keeps diverging from observed behaviour.
- Fuller detail on the campaign's persistence, which the source cuts off at SSH modification.
- Similar advisories for other AI gateways that let non-admin keys supply stdio server configuration.