LiteLLM MCP Test Endpoint Command Injection: From Authenticated to Unauthenticated RCE

critical CVE-2026-42271 Exploited in the wild · Disclosed · 4 min read

LiteLLM's MCP preview endpoints accepted full stdio server configurations, including arbitrary command paths and arguments, and spawned them as subprocesses on the proxy host with no allowlist and no administrative gate. Any holder of a proxy API key could run arbitrary code. Horizon3.ai then chained it with CVE-2026-48710, a host-header validation bypass in LiteLLM's Starlette dependency, to remove the API key requirement entirely. The combined chain scores CVSS 10.0, was confirmed exploited in the wild, and landed on CISA's Known Exploited Vulnerabilities catalogue on June 9, 2026. LiteLLM sits at the centre of many self-hosted AI stacks, concentrating provider API keys and model tokens in a single process that attackers can now reach with a single HTTP request.

What happened

LiteLLM is a widely deployed open-source AI gateway proxy, sitting between applications and model providers such as OpenAI and Anthropic. It centralises API key management and rate limiting for entire engineering teams, which makes it a high-value target: own the proxy, own every provider credential it holds.

Two endpoints designed for previewing MCP server configurations before saving them, POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list, accepted a full server configuration in the request body, including command, args, and env fields used by the STDIO transport. When called, LiteLLM spawned that input as a subprocess on the proxy host, inheriting the full privileges of the proxy process, with no command allowlist and no sandboxing. Any authenticated holder of a proxy API key could execute arbitrary commands on the host.

That authentication requirement collapsed on June 1, 2026, when Horizon3.ai demonstrated that CVE-2026-48710, a host-header validation bypass in Starlette, could sidestep the API key check entirely in deployments running Starlette versions at or below 1.0.0. The chained path required zero credentials. Horizon3.ai assessed the combined chain at CVSS 10.0.

CISA added CVE-2026-42271 to its Known Exploited Vulnerabilities catalogue on June 9, 2026, citing confirmed active in-the-wild exploitation. Multiple sources observed automated scanning and, in some cases, web shell deployment and credential exfiltration from compromised LiteLLM hosts.

The PolicyLayer angle

The root failure here is that LiteLLM exposed an MCP server spawn operation, the most dangerous primitive in the STDIO transport, through an endpoint that was only gated by a low-privilege credential. The policy layer equivalent of this failure is permitting any authenticated agent, regardless of role, to invoke tools that execute arbitrary processes. The control that stops it is a strict tool allowlist: MCP server spawn operations belong in a separate, administratively gated policy group, never exposed to standard API key holders.

The second failure is that the authentication gate itself was a transitive dependency, Starlette, rather than something baked into LiteLLM's own middleware. The lesson for policy enforcement: gate operations at the application layer on something you own and audit, not on a framework version you inherit implicitly. If LiteLLM had required the PROXY_ADMIN role at the handler rather than at the router, the Starlette bypass would have been irrelevant.

For deployments that cannot patch immediately, blocking /mcp-rest/test/connection and /mcp-rest/test/tools/list at the reverse proxy or API gateway is an effective compensating control. This is the deny-by-default principle applied at the perimeter: MCP test endpoints should be off by default and require an explicit allow decision before they are reachable from any network segment.

Mitigations

Upgrade LiteLLM to version 1.83.7 or later and Starlette to version 1.0.1 or later. If patching is not immediately possible, block POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list at the reverse proxy or API gateway, restrict LiteLLM to trusted network segments, and rotate all provider API keys and secrets stored by the proxy. Review process execution logs for unexpected child processes spawned by the LiteLLM process, particularly shell interpreters and network tools. Because CISA lists this as exploited, treat unpatched internet-facing deployments as compromised until proven otherwise and conduct forensic review of recent activity.

FAQs

Is a valid API key required to exploit this? +

Not once CVE-2026-48710 is in the chain. CVE-2026-42271 on its own required a valid proxy API key. Chained with the Starlette 'BadHost' host-header bypass (CVE-2026-48710), the authentication check is sidestepped entirely. Deployments running Starlette at or below 1.0.0 are fully unauthenticated RCE from any network-reachable host.

Why does LiteLLM hold so many credentials? +

LiteLLM functions as a centralised AI gateway, proxying requests to OpenAI, Anthropic, Mistral, and other providers under a single interface. Provider API keys, internal tokens, and sometimes database credentials are injected at container startup and loaded into the process environment. A successful exploit inherits all of them.

Is this related to the Qilin ransomware group? +

CybelAngel's analysis noted that CISA's KEV attribution tagged CVE-2026-42271 in connection with the Qilin ransomware group. The specific targeting pattern and infection chain have not been fully publicly detailed. Treat any unpatched, internet-facing LiteLLM instance as a high-priority exposure regardless of attribution.

References

Take your agents live. Without losing control.

Route your MCP traffic through PolicyLayer. Every tool call is checked against your policy before it runs: allow, deny, or require approval. Per-identity grants. Full audit log. Live in minutes.

Instant setup, no code required.

46,500+ MCP servers and 515,000+ tools scanned and risk-classified.

// GET IN TOUCH

Have a question or want to learn more? Send us a message.

Message sent.

We'll get back to you soon.