LiteLLM RCE (CVE-2026-42271): when an MCP "test connection" button spawns a shell

What happened

LiteLLM is an AI gateway — a proxy that gives one OpenAI-shaped API in front of many LLM providers. Recent versions can also broker MCP (Model Context Protocol) servers, and the admin UI has a convenience: preview an MCP server before you save it, so you can confirm it connects and see its tool list.

Two endpoints backed that preview — POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list. Both accepted a full MCP server configuration in the request body, including the command, args, and env fields that MCP's stdio transport uses to launch a local server process. When the config specified a stdio server, the endpoint did the natural thing: it tried to connect — which meant spawning the supplied command as a subprocess on the proxy host, with the privileges of the proxy process.

The only gate was a valid proxy API key. There was no role check. So any authenticated caller — including a holder of a low-privilege internal-user key — could hand the gateway an arbitrary command and have it executed on the host. That is the whole vulnerability: a preview feature that treats untrusted request input as a program to run.

Why this keeps happening to AI gateways

MCP's stdio transport is, by design, "here is a command line, launch it and talk to it over stdin/stdout." That is fine when the command comes from a trusted local config file written by an operator. It is remote code execution the moment that command can be supplied over the network by a user — which is exactly what a "test this server config" endpoint does. The classification says as much: this is CWE-77 / CWE-78, command injection into an OS command.

The lesson generalizes past LiteLLM: any feature that lets a caller describe a stdio MCP server and then connects to it is a command-execution sink. Preview/validate flows are a common place to forget the trust boundary, because they feel read-only. They are not.

Am I affected?

• Versions: LiteLLM from 1.74.2 up to (but not including) 1.83.7.
• Surface: the MCP preview endpoints POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list.
• Who can trigger it: anyone holding any valid proxy API key — no admin role required. If you issue internal-user or team keys, treat them as capable of host command execution until you patch.
• Exposure multiplier: an AI gateway usually sits close to provider credentials, internal networks, and secrets in env. RCE here is rarely low-impact.

Conceptually, the dangerous request looks like a normal "test this MCP server" call whose stdio command/args point at something the operator never intended to run:

POST /mcp-rest/test/connection
Authorization: Bearer <any-valid-proxy-key>
Content-Type: application/json

{
  "transport": "stdio",
  "command": "<attacker-controlled binary>",
  "args": ["..."],
  "env": { "...": "..." }
}

# The proxy launches `command` on the host to "connect" to it.

What to do now

1. Upgrade to LiteLLM 1.83.7 or later. This is the real fix.
2. If you can't patch immediately: the advisory documents a workaround — block or network-restrict the /mcp-rest/test/* preview endpoints, and stop issuing proxy keys to anyone who doesn't strictly need them.
3. Rotate proxy API keys and the provider/secret values in the gateway's environment, on the assumption any key holder could have reached the host.
4. Hunt for abuse: look for unexpected child processes of the LiteLLM process and for calls to /mcp-rest/test/connection or /mcp-rest/test/tools/list in access logs.
5. Least privilege for the gateway: run the proxy as an unprivileged user, in a sandbox/container with no outbound egress it doesn't need, so a future spawn is contained.