LiteLLM CVE-2026-42271: MCP stdio test RCE, CISA KEV

TL;DR

What happened LiteLLM 1.74.2 through <1.83.7 can execute arbitrary commands through MCP stdio test endpoints. By itself it requires a valid low-privilege proxy API key; chained with Starlette CVE-2026-48710, it becomes unauthenticated RCE.

What to do Patch the vulnerable deployment:

Upgrade LiteLLM to 1.83.7 or later
Upgrade Starlette to 1.0.1 or later
Rotate stored LLM provider keys if endpoint abuse or unusual subprocess execution appears in logs

What to block/check Until patched, block POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list. CISA added CVE-2026-42271 to KEV on June 8, 2026; the federal due date is June 22, 2026.

The Hacker News reported CVE-2026-42271 as exploited and chainable to unauthenticated RCE.
The GitHub Advisory and NVD entry for CVE-2026-42271 itself say PR:L, meaning the standalone bug requires low privileges.
It becomes unauthenticated only when chained with CVE-2026-48710, Starlette’s Host header handling bypass, in the same deployment.

The TeamPCP LiteLLM PyPI package compromise I wrote about in March was about the distribution channel itself being poisoned.
CVE-2026-42271 is different: even a legitimate LiteLLM Proxy deployment can reach host command execution when the MCP (Model Context Protocol) standard input/output (stdio) preview path and API-key permissions do not line up.
For this one, the things to check are the running proxy version, MCP-related endpoints, the Starlette dependency, and stored credentials, not package history.

The entry point is two MCP test endpoints

The affected range is LiteLLM 1.74.2 through <1.83.7.
The GitHub Advisory names two endpoints.

Endpoint	Intended use
`POST /mcp-rest/test/connection`	Test an MCP server configuration
`POST /mcp-rest/test/tools/list`	Fetch the tool list from an MCP server before saving it

These APIs preview an MCP server configuration before it is saved, but they accepted a complete server configuration in the request body.
For stdio transport, that configuration includes command, args, and env.
LiteLLM attempted to connect with that configuration, spawning the supplied command as a subprocess under the LiteLLM Proxy process privileges.

Before the fix, the access control only checked whether the proxy API key was valid.
The PROXY_ADMIN role was not required, so even a low-privilege internal-user key could call the test endpoints.
In 1.83.7, the test endpoints were restricted to PROXY_ADMIN, matching the save endpoint.

This resembles the “tool approval leads to automatic internal command execution” problem from the 50 open-source MCP server scan, but the vulnerable side is LiteLLM Proxy’s management API, not a local MCP server.
MCP stdio is designed around starting a command and speaking to the server over its standard streams.
If permission to submit a configuration is treated the same as permission to start a command, the result is host command execution.

The 1.83.7 fix is not just a role check

LiteLLM’s April security update and the fixing PR (#25343) show that 1.83.7 did more than require PROXY_ADMIN on the test endpoints.
It also narrowed which commands stdio transport can start, added request-time validation, and re-validates existing configurations when they are loaded again.

Layer	Change
Command allowlist	`npx`, `uvx`, `python`, `python3`, `node`, `docker`, and `deno` are allowed by default
Request validation	MCP stdio create/update requests check the basename of `command` against the allowlist
Runtime re-validation	Older MCP server definitions restored from DB/config are checked again before spawn time
Authorization	`/mcp-rest/test/connection` and `/mcp-rest/test/tools/list` require `PROXY_ADMIN`

Deployments that need additional stdio launchers can extend the allowlist with LITELLM_MCP_STDIO_EXTRA_COMMANDS.
Adding a shell or generic execution wrapper there reopens the boundary the patch is trying to close.
Even allowed entries such as python and node can run arbitrary code depending on arguments, so after 1.83.7 the people allowed to edit or test stdio MCP configurations should still be treated as administrators with code-execution power on the proxy host.

CVE-2026-30623 appears in LiteLLM’s April security update as a separate number.
That one is the broader OX Security MCP stdio issue around LiteLLM’s MCP server create, update, and preview paths.
CVE-2026-42271, the one added to CISA KEV, is described in the GitHub Advisory specifically as missing authorization on the two preview/test endpoints.
Even if you split tickets by CVE number, the operational response is the same: upgrade to LiteLLM 1.83.7 or later, review stdio MCP configurations, and verify that non-admin keys cannot reach the test APIs.

KEV makes this an exploited vulnerability

CISA’s Known Exploited Vulnerabilities JSON feed lists CVE-2026-42271 with dateAdded June 8, 2026 and a due date of June 22, 2026.
The required action is to apply vendor mitigations, follow BOD 22-01 guidance for cloud services when applicable, or discontinue use if mitigations are unavailable.

The CVSS scores differ slightly by source.
GitHub gives CVSS v4.0 score 8.7 HIGH.
NVD gives CVSS 3.1 score 8.8 HIGH with vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H.
AV:N means it is reachable over the network, PR:L means low privileges are required, and UI:N means no user interaction is required.

CISA’s short description also mentions any authenticated user, including users with low-privilege internal-user keys.
That “low privilege is enough” point is easy to miss in the standalone CVE.
In environments that issue proxy keys to ordinary LiteLLM users, protecting only the administrator key still leaves a path from the MCP test endpoints to the proxy host’s privileges.

Starlette BadHost removes the authentication condition

Horizon3.ai validated the chain between CVE-2026-42271 and CVE-2026-48710.
CVE-2026-48710 is a Host header validation issue in Starlette before 1.0.1. The NVD description says Starlette rebuilt request.url from the HTTP Host header without validating it, allowing the actual requested path and request.url.path to diverge.
Middleware or endpoints that make path-based authorization decisions from request.url can then bypass the intended auth check.

In Horizon3.ai’s validation, that bypass removes the “valid proxy API key required” condition for CVE-2026-42271 when the LiteLLM deployment includes Starlette 1.0.0 or earlier.
Sending a stdio configuration to /mcp-rest/test/connection or /mcp-rest/test/tools/list in that state becomes unauthenticated RCE.
Starlette’s own CVSS is 6.5 MEDIUM, but when path-based authorization and command-execution endpoints sit in the same LiteLLM app, the combined result is much worse than the standalone score.

CVE-2026-48710 is not “using Starlette means instant RCE.”
The Starlette Advisory describes a mismatch: routing uses the real HTTP path, while application authorization code may read request.url.path, which can be poisoned through a malformed Host header.
The chain depends on the combination of Starlette 1.0.0 or earlier, security logic that reads request.url / request.url.path, and the malformed request reaching the application.

OSTIF’s BadHost writeup says fronting the app with nginx, Apache httpd, Cloudflare, or another layer that rejects or normalizes malformed Host headers can mitigate the issue. Verify the actual configuration rather than assuming it.
If LiteLLM or another LLM gateway such as vLLM is exposed directly through an ASGI server like uvicorn or granian, do not assume a front proxy is protecting it.
For HTTP/3 and QUIC frontends, verify Host handling separately; it may not match the HTTP/1.1 path you tested.

Check the credentials held by the proxy

The patch target is LiteLLM 1.83.7 or later and Starlette 1.0.1 or later.
If you cannot upgrade immediately, the GitHub Advisory recommends blocking POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list at the reverse proxy or API gateway.
Horizon3.ai additionally recommends restricting network reachability, rotating credentials stored by the proxy, and reviewing logs for unusual Host headers and subprocess execution.

LiteLLM Proxy is an LLM API gateway, so provider keys for OpenAI, Anthropic, Bedrock, Azure OpenAI, and similar services often sit in the process environment or database.
Stopping at “did RCE happen?” misses the follow-on risk of abused provider keys.
After a KEV listing, the practical order is: running LiteLLM version, Starlette dependency, access logs for the two MCP test endpoints, suspicious subprocesses on the proxy host, and rotation of stored LLM provider keys.

Check the versions inside the running LiteLLM Proxy container or virtual environment, not just in the host Python environment.
With bundled Docker images or old virtualenvs, pip list on the host may not match the process that is actually serving traffic.

python - <<'PY'
import importlib.metadata as m

for package in ("litellm", "starlette", "fastapi"):
    try:
        print(f"{package}: {m.version(package)}")
    except m.PackageNotFoundError:
        print(f"{package}: not installed")
PY

For containers, run the same check with docker exec <container> python ....
If LiteLLM is 1.74.2 through <1.83.7, or Starlette is 1.0.0 or earlier, prioritize it even when the instance is not internet-facing.
Proxy instances placed on a VPN, internal LAN, CI/CD network, or temporary test subdomain often have low-privilege and developer keys distributed more widely than administrators realize.

At minimum, search logs for these paths.

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

Also check for Host headers that normal traffic would not use, child processes spawned by the LiteLLM process, and suspicious outbound connections from inside the container.
If anything shows up, rotate not only LiteLLM API keys but also the LLM provider keys, cloud credentials, and database credentials held by the proxy.

runZero’s LiteLLM instance discovery article also groups CVE-2026-42208, CVE-2026-42203, and CVE-2026-42271 as LiteLLM vulnerabilities that can chain toward RCE.
CVE-2026-42208 is the pre-auth SQL injection disclosed in April, with exploitation evidence already published in May.
For LiteLLM, track proxy authentication, MCP stdio, the Starlette dependency, and stored keys at the instance level.