CVE-2026-42271: The LiteLLM Gateway Bug That Chains to Unauthenticated RCE

If your team runs LiteLLM as the gateway in front of OpenAI, Anthropic, Google, or your own model endpoints, stop and check your version before reading the rest of this post. CVE-2026-42271 is being actively exploited, CISA has added it to the Known Exploited Vulnerabilities catalog, and it chains into full unauthenticated remote code execution against your AI infrastructure.

What the vulnerability actually is

LiteLLM is one of the most widely deployed AI gateways: a proxy that sits between your applications and every LLM provider you talk to, handling routing, retries, cost tracking, and (critically) holding the API keys for each provider. That last part is what makes this bug dangerous.

The flaw lives in two endpoints: /mcp-rest/test/connection and /mcp-rest/test/tools/list. Both were built to let an admin test an MCP (Model Context Protocol) server connection before wiring it into production. To do that, they accept a server configuration in the request body, including command, args, and env fields, and pass that configuration directly into a subprocess call.

There’s no allowlist of permitted commands. There’s no restriction limiting the endpoint to admin roles. There’s no sandbox isolating the spawned process from the host. If you can reach the endpoint with valid credentials, you can supply your own command and run it.

Why this is worse than a normal authenticated bug

A vulnerability that needs valid credentials is bad, but it’s a smaller blast radius than one that doesn’t. CVE-2026-42271 was originally reported as requiring authentication, which limited who could realistically hit it.

Then Horizon3.ai published a chain. CVE-2026-48710, nicknamed “BadHost,” is a host-header validation bypass in Starlette (the ASGI framework underneath FastAPI, which LiteLLM is built on). Starlette’s own maintainer rated it a moderate 6.5 on CVSS; independent researchers at X41 D-Sec put it at 7.0. The disagreement doesn’t matter much once you see what it enables: crafting a malformed Host header lets an attacker skip host-validation checks that would otherwise gate access to internal-only endpoints.

Chain the two together and the authentication requirement on CVE-2026-42271 disappears. An attacker with no credentials at all can reach the command-injection endpoint and get a shell.

CVE	Component	What it does alone	CVSS
CVE-2026-42271	LiteLLM	Command injection via MCP test endpoints (needs auth)	8.7
CVE-2026-48710	Starlette	Host-header validation bypass (“BadHost”)	6.5–7.0 (disputed)
Chained	LiteLLM + Starlette	Unauthenticated remote code execution	Critical in practice

Who is affected

LiteLLM versions 1.74.2 through 1.83.6 carry the vulnerable endpoint. If you’re running a self-hosted LiteLLM proxy, gateway, or admin UI anywhere between those version bounds, and it’s reachable from an untrusted network (which for a lot of teams means the public internet, because the whole point of a gateway is that other services can call it), you’re exposed.

This isn’t a niche deployment pattern. LiteLLM’s proxy mode is a common way to centralize provider billing, add fallback routing between models, and enforce rate limits across a team. If your setup looks anything like the routing patterns in our LLM routing production guide, it’s worth the five minutes to check your version now.

pip show litellm | grep Version
# or, if running the proxy via Docker
docker exec <litellm-container> pip show litellm

Patching, and why you need both halves

The fix is to upgrade LiteLLM to 1.83.7 or later. That patches the command injection at the source: the MCP test endpoints now validate and restrict what can be passed to the subprocess call.

But if you only patch LiteLLM and leave an old Starlette version underneath it, the host-header bypass is still there. It just means the specific chain researchers demonstrated might need a different entry point to reach the now-patched endpoint. The safer assumption is to patch both:

pip install --upgrade litellm>=1.83.7
pip install --upgrade starlette>=1.0.1

# If LiteLLM pins its own Starlette dependency, check requirements.txt
# or pyproject.toml doesn't silently downgrade it back
pip show starlette | grep Version

For containerized deployments, rebuild from the updated base rather than patching in place:

# Bump both in your requirements before rebuilding
# litellm>=1.83.7
# starlette>=1.0.1
FROM python:3.12-slim
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

If you can’t patch right now

Patching takes a deployment window; blocking an endpoint doesn’t. If you run LiteLLM behind an nginx, Envoy, or cloud load balancer, block the two vulnerable paths immediately as a stopgap:

location ~ ^/mcp-rest/test/(connection|tools/list) {
    return 403;
}

This isn’t a substitute for the upgrade. It closes the specific paths researchers have demonstrated, but it doesn’t fix the underlying flaws, and a determined attacker who finds another route to the same subprocess call isn’t stopped by it. Treat it as buying time until the real patch lands.

The broader pattern worth noticing

This is the second AI-infrastructure-specific CVE chain to hit widely-deployed tooling this year, and the shape is becoming familiar: a convenience feature (here, a “test your MCP connection before you commit to it” endpoint) built without the same threat model you’d apply to a production API, sitting in software that now holds credentials for every model provider a team uses. The npm supply chain attacks we covered in June targeted a different layer of the stack, but the underlying lesson is the same: the tooling wrapped around AI infrastructure is now valuable enough to be a primary target, not an afterthought.

If your team runs any AI gateway, proxy, or MCP-adjacent tooling in production, this is a good week to audit which admin and debug endpoints are reachable without a VPN or an allowlist, not just LiteLLM’s. Test-and-debug endpoints get bolted on quickly and reviewed less carefully than the request path your users actually hit, and that gap is exactly where this bug lived.

Patch LiteLLM to 1.83.7+, patch Starlette to 1.0.1+, and block the MCP test endpoints at your edge if you can’t do both today.