LiteLLM MCP Endpoints Chain to Unauthenticated RCE, CISA Warns

CISA added CVE-2026-42271 to its Known Exploited Vulnerabilities catalog on June 8, confirming active exploitation in the wild. Horizon3.ai had already published a chain that escalates the original command injection flaw to unauthenticated remote code execution against LiteLLM AI gateway deployments.

What the Vulnerability Is

LiteLLM is an open-source AI gateway that routes requests across multiple LLM providers behind a single API. Two of its endpoints — POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list — let users preview an MCP server configuration before saving it.

Both endpoints accepted a full server configuration in the request body, including the command, args, and env fields used by the stdio transport. There was no sanitisation. An attacker who could reach these endpoints with a valid API key could inject arbitrary commands into the server configuration and have them execute on the host with the privileges of the LiteLLM process.

CVE-2026-42271 was disclosed on April 20 and patched in version 1.83.7 on May 8. Six weeks passed between patch release and CISA’s KEV addition, with active exploitation confirmed during that window.

The Authentication Bypass

The initial severity assessment assumed an attacker needed a valid API key. Horizon3.ai changed that assessment.

CVE-2026-48710 is a host header validation bypass in Starlette, the Python web framework underlying LiteLLM. Chaining the two CVEs sidesteps the API key requirement entirely. The result is unauthenticated remote code execution against any LiteLLM deployment running a vulnerable version that is reachable from the network.

The chain matters because “internal-only” is a weaker boundary than it sounds in many environments. CI runners, developer workstations, and compromised third-party services can often reach the same network segments as internal AI infrastructure. Supply chain attacks that land code in the build environment are one hop from an AI gateway.

The Blast Radius

LiteLLM’s value to organisations is that it holds API keys for every LLM provider they have integrated. OpenAI, Anthropic, Azure, Google, and others — all stored in the gateway’s environment. Code execution on the LiteLLM host gives an attacker access to those keys, the ability to move laterally into connected AI infrastructure, and potentially the ability to silently modify how the proxy routes future requests.

For organisations routing sensitive data through LiteLLM, the gateway has seen that data. Logs, memory, and any stored context are accessible to an attacker with code execution.

This is the core security argument for treating AI gateway infrastructure with the same rigor as production API infrastructure. The gateway is not just passing through benign requests. It holds credentials for multiple providers and processes data that, in many deployments, is sensitive enough to warrant LLM-level analysis in the first place.

Remediation

Upgrade to version 1.83.7 or later. CISA’s KEV deadline for federal agencies is June 22. Treat that as the outer boundary, not the target date.

If immediate patching is not possible, restrict network access to the two MCP test endpoints at the gateway or firewall level. These are test-and-preview endpoints that most production deployments should not be exposing to the network at all.

References

• CISA — Known Exploited Vulnerabilities Catalog
• Help Net Security — LiteLLM vulnerability under active attack, CISA warns (CVE-2026-42271)
• The Hacker News — LiteLLM Flaw CVE-2026-42271 Exploited in the Wild, Chains to Unauthenticated RCE
• Rescana — Active Exploitation Alert: CVE-2026-42271 and CVE-2026-48710 — Unauthenticated RCE in LiteLLM AI Gateway via Starlette Host Header Bypass
• SOCRadar — CISA KEV Highlights LiteLLM RCE (CVE-2026-42271) and Check Point VPN Auth Bypass (CVE-2026-50751)
• MITRE ATT&CK — T1059: Command and Scripting Interpreter