CVE-2026-42271

What it actually does

Authenticated command injection on the LiteLLM proxy host. Two MCP preview endpoints accepted a full stdio-transport server configuration (command, args, and env) and spawned that command as a subprocess with the privileges of the proxy process. Access was gated only by a valid proxy API key, with no role check, so low-privilege internal-user keys were sufficient for arbitrary command execution, full host confidentiality/integrity impact, and potential follow-on access to the proxy’s secrets and downstream LLM credentials.

Why it matters to the business

Compromise of the AI gateway can expose provider API keys, prompts, and enterprise data in transit through the proxy, disrupt LLM-backed applications, and give an attacker a foothold on the host running the gateway. This CVE is in CISA KEV with a remediation due date of 2026-06-22, is reported as exploited in the wild, and has a very high and rising EPSS (0.8359 → 0.9257 over 30 days). Organizations still running 1.74.2 through versions before 1.83.7 more than four months after publication face elevated operational and regulatory risk if the gateway remains unpatched.

How an attack unfolds

An attacker who already holds any valid LiteLLM proxy API key—including a low-privilege internal-user key—targets the MCP server preview API rather than a saved MCP configuration. They submit a stdio-transport configuration to POST /mcp-rest/test/connection or POST /mcp-rest/test/tools/list. The proxy treats the body as a live server to probe, launches the supplied command on the gateway host, and returns connection or tool-list results. Because those endpoints performed no role check, this yields remote command execution as the proxy user. Public reporting associates in-the-wild activity with this LiteLLM command-injection issue; follow-on abuse typically focuses on harvesting environment secrets, LLM provider keys, and using the gateway host as a pivot—not ransomware-specific campaigns.

How to fix it

Upgrade LiteLLM to 1.83.7 or later, which patches the MCP test endpoints so they no longer spawn attacker-supplied stdio commands for unprivileged callers. If an immediate upgrade is not possible, disable or block POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list at the reverse proxy or WAF, restrict proxy API keys to administrators who must manage MCP servers, rotate all proxy and provider keys that may have been exposed, and run the gateway with least privilege (non-root, tight filesystem and network controls, no unnecessary shell tools). After upgrading, rotate keys and review MCP server definitions that were added around the time of exposure.

How to confirm the fix worked

Confirm the running LiteLLM version is 1.83.7 or newer. Verify the MCP test/preview endpoints either reject stdio command/args/env from non-admin keys or no longer execute host commands during preview. Inventory API keys and roles to ensure internal-user keys cannot reach MCP administration. Review reverse-proxy/WAF rules for blocks on /mcp-rest/test/connection and /mcp-rest/test/tools/list if those paths should not be exposed. Check process-audit and container runtime policy to ensure the proxy cannot spawn unexpected children. Do not validate by sending command-execution payloads against production.

Typical attack path

1. Obtain or reuse a valid LiteLLM proxy API key (including a low-privilege internal-user key).
2. Authenticate to the proxy and locate the MCP preview/test API.
3. Submit a stdio-transport server configuration (command, args, env) to POST /mcp-rest/test/connection or POST /mcp-rest/test/tools/list.
4. The proxy spawns the supplied command as a subprocess with the proxy process privileges.
5. Use the resulting host access to read proxy configuration, environment variables, and stored provider credentials.
6. Abuse stolen keys or the compromised gateway to access downstream LLM APIs or move laterally from the host.

How to detect it

Hunt whether this was already abused by correlating authenticated POST requests to /mcp-rest/test/connection and /mcp-rest/test/tools/list with request bodies that include stdio transport fields (command, args, env), especially from internal-user or otherwise low-privilege keys. On the proxy host, look for the LiteLLM/gateway process spawning short-lived unexpected children (shells, scripting runtimes, recon or credential-file access) at the same timestamps. Review API gateway, reverse-proxy, and application logs for those paths; container runtime, auditd/EDR process-creation events, and secret-access logs for the proxy service account; and outbound connections from the gateway host that are inconsistent with normal LLM provider traffic. Public reporting of in-the-wild exploitation of this LiteLLM command-injection issue should raise priority for any historical hits after 2026-05-08. Successful abuse may not leave a unique malware family; prioritize request+process correlation and subsequent credential use.

• POST /mcp-rest/test/connection
• POST /mcp-rest/test/tools/list
• /mcp-rest/test/connection
• /mcp-rest/test/tools/list
• "transport":"stdio"
• "command":
• stdio transport MCP test request from internal-user API key
• litellm spawning unexpected child process (sh, bash, python, curl, wget) coincident with MCP test API call

What your security team should do

• Treat this as KEV-priority: patch all LiteLLM 1.74.2–<1.83.7 instances to 1.83.7+ immediately given in-the-wild exploitation and the 2026-06-22 CISA due date.
• Block or authenticate-and-restrict the MCP test endpoints at the edge until every instance is upgraded.
• Rotate LiteLLM proxy keys and all LLM provider credentials stored in the gateway environment or config.
• Hunt historical access logs and process telemetry for the detection guidance and IOCs below; assume keys are burned if those endpoints were reachable to internal-user keys.
• Run the proxy as a non-root user with no unnecessary interpreters or cloud-credential files on the host, and segment it from sensitive networks.
• Add regression tests and WAF/positive-security rules so MCP preview APIs cannot accept stdio command execution from low-privilege keys.