LiteLLM CVE-2026-42271: Patch, Rotate, and Harden the RCE

What Is CVE-2026-42271 and Why It Hit CISA's KEV List

CVE-2026-42271 is a command injection vulnerability in LiteLLM, the most widely deployed open-source AI model gateway. It carries a CVSS score of 8.7. The flaw lives in two endpoints meant to preview an MCP server before you save it: POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list. Both accepted a full server configuration in the request body, including the command, args, and env fields that the stdio transport uses.

Here is the problem. To "test" an MCP server over stdio, LiteLLM spawned the supplied command as a subprocess on the proxy host. No sandbox, no allowlist. Send a config whose command is your own binary and the proxy runs it for you. That turns a convenience feature into arbitrary code execution as the LiteLLM process.

CISA added CVE-2026-42271 to its Known Exploited Vulnerabilities catalog on June 9, 2026, citing confirmed active exploitation in the wild (Help Net Security, June 9 2026). A KEV listing is not a theoretical advisory. It means attackers are already using it, and for US federal agencies it triggers a mandatory remediation deadline. If you run LiteLLM in production, treat this as an incident, not a backlog item.

Is My LiteLLM Proxy Vulnerable? How to Detect Exposure

You are vulnerable if you run LiteLLM 1.74.2 through 1.83.6 with the proxy reachable by untrusted clients. Start with the version check, then confirm whether the test routes are actually exposed, then go hunting in your logs.

Step 1 - check the installed version.

# Direct pip install
pip show litellm | grep -i version

# Or ask the package itself
python -c "import litellm; print(litellm.__version__)"

# Running in Docker? Check the pinned tag
docker inspect ghcr.io/berriai/litellm:main-latest --format '{{.Config.Image}}'

If the version sits anywhere in the 1.74.2 to 1.83.6 range, you are running affected code. The fix landed in 1.83.7.

Step 2 - confirm whether the test routes are reachable. The danger is highest when the proxy is internet-facing. A quick probe from outside your network tells you what an attacker sees.

# A 401/403 means auth is in front of the route (still patch, but lower urgency).
# A 200 or a 422 validation error means the route is processing your body. Patch now.
curl -s -o /dev/null -w "%{http_code}\n" \
  -X POST https://your-litellm-host/mcp-rest/test/tools/list \
  -H "Content-Type: application/json" \
  -d '{}'

Step 3 - hunt your access logs. Look for POSTs to either test endpoint, and pay attention to odd Host headers (a sign of the BadHost bypass) and any payloads carrying command or env values.

# Grep an nginx-style access log for hits on the vulnerable routes
grep -E "POST /mcp-rest/test/(connection|tools/list)" /var/log/nginx/access.log

# Flag requests with suspicious Host headers (BadHost uses ? or # in the host)
grep -E 'Host:[^"]*[?#]' /var/log/nginx/access.log

runZero published guidance on fingerprinting LiteLLM proxies across a fleet if you need to find every instance, not just the one you know about (runZero). Treat any log hit during the active-exploitation window as a confirmed compromise and move straight to credential rotation.

Why Patching Is Not Enough: Rotate Compromised Credentials

This is the step nearly every news article skips, and it is the one that actually protects you. RCE means an attacker could run code as the LiteLLM process, which means they could read environment variables, your config.yaml, and the database the proxy talks to. Upgrading stops the next attacker. It does not invalidate a secret a previous attacker already copied. If your proxy was exposed during the active-exploitation window, assume every secret it could see is now public.

A LiteLLM gateway is the worst possible thing to have compromised because it concentrates every downstream credential in one place. Rotate all of them, in roughly this order:

Partial rotation is a trap. Rotating the provider keys but leaving the master key alone means the attacker can mint fresh virtual keys at will. The March 2026 supply-chain incident already proved that LiteLLM credential exfiltration happens at scale, so this is not a hypothetical. Rotate the full set, then watch provider billing dashboards for anomalous usage over the following days.

Should You Still Trust LiteLLM?

Two critical incidents in three months is a fair reason to pause. My honest take: LiteLLM is still usable, but only if you stop treating it like a harmless proxy and start treating it like the high-value target it is. It is the most popular open-source AI gateway, and popularity buys it both more attacker attention and a maintainer team that ships fixes quickly. The June flaw was patched, and the broader Starlette bug was patched upstream within a day of public disclosure.

The real failure in most exploited deployments was not running LiteLLM. It was running it internet-facing with admin routes open and provider keys one RCE away from the public. The same gateway behind a network allowlist, running unprivileged, with scoped keys and a patch cadence, is a reasonable thing to operate. I run MCP servers in production myself, including the Jenkins MCP server, and the lesson is consistent: the danger is rarely the tool, it is the deployment.

If you cannot commit to a fast patch cadence and network isolation, that is a real signal that a direct-exposed gateway is the wrong shape for your team. Defense in depth, not abandonment, is the answer for everyone else.