LiteLLM's MCP test endpoints: command injection now under active exploitation

What is this?

LiteLLM is one of the most widely deployed open-source AI gateways: a proxy that gives internal AI consumers a single OpenAI-compatible interface in front of a hundred-plus model providers. A high-severity command-injection flaw in its Model Context Protocol (MCP) test endpoints lets any holder of a proxy API key run arbitrary commands on the gateway host. LiteLLM shipped the fix in version 1.83.7 on May 8, 2026; all releases from 1.74.2 through 1.83.6 are affected.

The reason this one matters beyond the usual CVE churn is the timeline. On June 8, 2026, CISA added the flaw to its Known Exploited Vulnerabilities (KEV) catalog after confirming active in-the-wild exploitation — roughly five weeks after the patch. The Cloud Security Alliance’s AI Safety Initiative published a detailed research note on June 13, 2026, and mainstream security press reported exploitation activity beginning shortly after the advisory. This is a patched, publicly disclosed vulnerability being weaponised against unpatched gateways right now.

How it works

The flaw sits in two endpoints added to support LiteLLM’s MCP integration: POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list. They were meant to let an operator preview an MCP server before saving it, so they accept a full server configuration inline in the request body — mirroring the MCP stdio transport, with command, args and env fields that describe a subprocess to launch on the proxy host.

The root cause is a combination of two omissions: no authorization gate (the endpoints were not restricted to an administrative role) and no safe handling of caller-controlled process configuration (no command allowlist, no sandbox). Any principal with a valid proxy API key — a credential routinely handed to developer teams and automated services just to reach models — could therefore cause the proxy to execute a supplied command. The standalone flaw scores CVSS 8.7; only the API-key requirement kept it out of critical territory.

That requirement disappears when the flaw is chained. Researchers at Horizon3.ai demonstrated combining it with the BadHost authentication-bypass flaw in Starlette — a Host-header desynchronisation that breaks path-based auth in FastAPI-based services. A forged Host header slips past the middleware, and the request reaches the vulnerable MCP endpoint with no credential at all, producing unauthenticated remote code execution rated CVSS 10.0.

No exploit string is reproduced here; the mechanism above is drawn entirely from the public advisories.

Why it matters

AI gateways occupy a structurally privileged position. A production LiteLLM deployment typically holds provider API keys for every model it routes to, database credentials for usage logging, and the policy configuration controlling which teams reach which models. Code execution on that host therefore does not stop at the gateway: it exposes the entire concentrated credential surface behind it, and in Kubernetes deployments an over-scoped service account can extend the reach to the cluster control plane.

The wider lesson is a pattern, not a single bug. Convenience features — an inline “test this MCP server” endpoint — were shipped without the authorization controls appropriate to a component that fronts all AI traffic. That is the same failure class that produced earlier LiteLLM issues this year, including a pre-auth SQL injection in the proxy. AI middleware is now a first-order target, and it deserves a security posture comparable to identity and access management systems rather than that of an internal developer tool.

Defenses

Upgrade immediately. Move LiteLLM to 1.83.7 or later, which restricts the MCP test endpoints to the PROXY_ADMIN role, and upgrade Starlette to 1.0.1 in the same cycle. Without the Starlette update the unauthenticated chain remains exploitable even against patched LiteLLM code.

Shrink exposure if you cannot patch today. Remove public internet access to the proxy and restrict reachability to the services that genuinely need it. This alone eliminates the external unauthenticated path while you schedule the upgrade.

Rotate and reduce credentials. Treat any gateway that ran a vulnerable version as potentially compromised: rotate every provider API key the proxy held, and revoke proxy API keys distributed to users or services without an active need. Fewer key holders means fewer principals who could trigger the flaw even without the Host-header bypass.

Hunt for compromise. Look for unexpected processes spawned by the LiteLLM service account, new files in cron or systemd directories, unfamiliar outbound connections from the proxy host, and unexplained changes to environment variables or the LiteLLM database.

Fix the class, not just the CVE. Enforce role-based access control on every administrative operation rather than a flat API-key model, segment AI middleware onto its own network plane, and audit the broader Starlette ecosystem — FastAPI services, vLLM servers, MCP frameworks — for the same Host-header bypass independent of any direct LiteLLM exposure.

Status

Item	Reference	Date	Notes
Standalone command injection	CVE-2026-42271 (NVD)	disclosed 2026	CVSS 8.7; MCP test endpoints, any proxy API key
Fixed release	LiteLLM 1.83.7	2026-05-08	Endpoints gated to PROXY_ADMIN; Starlette bumped to 1.0.1
Chained unauthenticated RCE	with CVE-2026-48710 (BadHost)	2026	CVSS 10.0; Host-header auth bypass in Starlette
CISA KEV listing	CISA KEV catalog	2026-06-08	Confirmed active in-the-wild exploitation
CSA research note	Cloud Security Alliance	2026-06-13	AI gateway credential-surface analysis
Affected versions	LiteLLM 1.74.2 → 1.83.6	—	Upgrade to 1.83.7+

The takeaway for builders: an AI gateway concentrates the credentials of everything it fronts, so a convenience endpoint on it is never low-stakes. Patch to 1.83.7 and Starlette 1.0.1, pull the proxy off the public internet, rotate the keys it held, and treat AI middleware with the same rigour you apply to your identity systems.