system: OPERATIONAL
← back to all hacks
INFRASTRUCTURE CRITICAL NEW

LiteLLM CVE-2026-42271: MCP test endpoints chain to unauthenticated RCE

Disclosed in April as an authenticated command injection, LiteLLM's MCP preview endpoints became unauthenticated RCE once chained with Starlette's BadHost bypass — CISA added it to KEV on June 8, 2026.

2026-06-10 // 6 min affects: litellm-proxy, starlette, ai-gateways

What is this?

On June 8, 2026, CISA added CVE-2026-42271 to its Known Exploited Vulnerabilities catalog, confirming that a command-injection flaw in LiteLLM — the popular open-source AI gateway that fronts many model providers behind a single OpenAI-compatible API — is being exploited in the wild. US federal civilian agencies were ordered to remediate by June 22, 2026.

What makes this one notable is not the bug alone but the chain. CVE-2026-42271 was publicly disclosed in April 2026 as an authenticated command injection. On June 1, 2026, Horizon3.ai researchers showed that pairing it with CVE-2026-48710 — the Starlette “BadHost” Host-header validation bypass — removes the authentication requirement entirely, turning an admin-adjacent bug into unauthenticated remote code execution with a combined CVSS of 10.0. This is the second LiteLLM flaw added to KEV in a month, after the CVE-2026-42208 SQL injection.

How it works

The vulnerable surface is LiteLLM’s MCP-server preview feature. Two endpoints used to test an MCP server before saving it —

POST /mcp-rest/test/connection
POST /mcp-rest/test/tools/list

— accept a full server configuration in the request body, including the command, args, and env fields used by the stdio transport. When the endpoint tries to “connect,” it spawns the supplied command as a subprocess on the proxy host, inheriting the privileges of the LiteLLM process. The endpoints were gated only by a valid proxy API key with no role check, so any authenticated user — even a holder of a low-privilege internal-user key — could run host commands. This is the same stdio-transport-spawns-a-process design hazard we covered in MCP stdio transport RCE.

The chain closes the remaining gap. BadHost (CVE-2026-48710) is a Host-header validation bypass in Starlette ≤ 1.0.0, the ASGI framework LiteLLM uses to handle HTTP. Where a deployment’s authentication relies on host/origin checks, BadHost lets an attacker sidestep it — so the “you need a key” precondition disappears.

# Conceptual only — no working payload.
attacker --> [BadHost host-header bypass]      # CVE-2026-48710: skip auth
         --> POST /mcp-rest/test/connection    # CVE-2026-42271: stdio config
         --> subprocess runs as LiteLLM proxy  # arbitrary command on host

Successful exploitation lets an attacker execute commands on the gateway host, read model-provider credentials and API keys the proxy stores, and pivot into connected AI infrastructure.

Why it matters

An AI gateway is a high-value target by design: it concentrates the keys to every model provider an organization uses and sits inline on a lot of internal traffic. An unauthenticated RCE there is a credential-theft and lateral-movement engine, not just a single-host compromise. The exposure is widened by the fact that the trigger is a convenience feature — previewing an MCP server before saving it — that many operators would not flag as security-sensitive.

Note the gap between the two CVEs’ confirmed status: CISA confirms active exploitation of CVE-2026-42271 itself, but as of disclosure there was no public confirmation that attackers are using the BadHost bypass in the same campaigns. Defenders should assume the chain is viable and patch both, rather than wait for that confirmation.

Defenses

  • Patch both components. Upgrade LiteLLM to v1.83.7 or later (it restricts the test endpoints to the PROXY_ADMIN role and updates Starlette) and Starlette to v1.0.1 or later.
  • If you can’t patch immediately: block external access to /mcp-rest/test/connection and /mcp-rest/test/tools/list, restrict the gateway to trusted network segments, and rotate every credential the proxy holds — assume keys may already be exposed.
  • Don’t expose the gateway to the internet. An AI proxy holding provider keys belongs behind authentication and network controls, not on a public IP.
  • Hunt for the IOCs Horizon3 published: requests to the two MCP test endpoints, unusual Host header values (possible BadHost abuse), and unexpected subprocess execution from the LiteLLM process.
  • Treat stdio-transport config as code execution. Any feature that accepts a command/args and spawns a subprocess is an RCE primitive; gate it on strong authorization and never on a bare API key.

Status

ItemDetail
CVE-2026-42271Command injection in LiteLLM MCP test endpoints (auth, originally)
CVE-2026-48710Starlette “BadHost” Host-header validation bypass (≤ 1.0.0)
Chained CVSS10.0 (unauthenticated RCE), per Horizon3.ai
AffectedLiteLLM 1.74.2–1.83.6; Starlette ≤ 1.0.0
Fixed inLiteLLM v1.83.7; Starlette v1.0.1
DisclosedCVE-2026-42271: Apr 2026 · BadHost: May 26, 2026 · chain: Jun 1, 2026
KEV / deadlineAdded to CISA KEV June 8, 2026; federal remediation by June 22, 2026

Sources