CISA Confirms Exploitation of LiteLLM MCP Preview Command Injection

CISA added CVE-2026-42271, a command-injection flaw in LiteLLM, to its Known Exploited Vulnerabilities catalog on June 8. The agency has not published details about the attackers or affected organizations, but the listing confirms exploitation outside a research setting.

The bug allowed any authenticated LiteLLM proxy-key holder to run commands on the proxy host. Administrator access was not required. LiteLLM fixed the issue in version 1.83.7 by restricting the affected endpoints to the PROXY_ADMIN role.

A connection test launched a subprocess

LiteLLM’s advisory identifies two vulnerable endpoints:

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

Both endpoints previewed an MCP server configuration before it was saved. A request could provide the command, args and env fields used by the stdio transport. When LiteLLM tested that configuration, it tried to connect by spawning the supplied command as a subprocess.

The command inherited the operating-system privileges of the LiteLLM proxy process. The only access check was a valid proxy API key, and there was no role check. A low-privilege internal-user key was enough.

Affected releases start at 1.74.2 and end before 1.83.7. GitHub scored the issue 8.7 under CVSS 4.0, while NVD lists an 8.8 CVSS 3.1 score. The more useful detail for responders is the permission mismatch: an ordinary authenticated key could reach behavior that started a process on the server.

Host access depends on how the proxy was deployed

Successful exploitation gave the attacker the same local access as the LiteLLM process. What that exposed will differ by environment.

A container with a narrow service account, read-only filesystem and no mounted secrets presents a smaller problem than a long-running proxy with environment-backed provider keys, writable volumes and broad network access. The vulnerability record does not establish which credentials attackers obtained in reported incidents. Responders need to determine that from each deployment.

Start with the process identity and its environment. Review mounted files, secret injection, service-account permissions, network routes, database access and any sockets or host paths shared with the container. Then list the model-provider credentials and LiteLLM keys that the process could read or use.

This scope should come from observed access, not from an assumption that every LiteLLM deployment holds the same secrets.

The public exploitation record is thin

CISA’s catalog entry names the flaw as an exploited LiteLLM command-injection vulnerability. It set a June 22 remediation deadline for federal civilian agencies and directs organizations to apply the vendor’s mitigation or stop using the product when mitigation is unavailable.

CISA does not identify an actor, initial-access method, payload or indicator in the catalog. The LiteLLM advisory explains how an authenticated key reaches command execution, but it does not describe the observed attacks. Those limits should remain visible in incident reports.

The available evidence supports a hunt for use of the two preview endpoints and subprocesses launched by the LiteLLM process. It does not support claims about a particular malware family, stolen provider accounts or a broader attack chain unless local evidence supplies them.

Patch first, then reconstruct access

Upgrade LiteLLM to 1.83.7 or later. The patched release requires PROXY_ADMIN for both preview endpoints, matching the permission applied to the save operation.

When an immediate upgrade is not possible, LiteLLM recommends blocking both endpoint paths at the reverse proxy or API gateway. That workaround should be temporary. It does not correct the application permission model and may be bypassed if the proxy is reachable through another route.

Review HTTP, reverse-proxy and application logs for requests to the two paths. Retain request bodies when policy and data handling rules allow it, because the supplied command, args and env values may show exactly what ran. On the host or container, look for child processes whose parent is LiteLLM, along with new files, outbound connections and persistence created in the same time window.

If exploitation is found, or if the relevant telemetry is missing, rebuild the affected host or container from a known image. Rotate LiteLLM keys and any other credentials the proxy process could access. Avoid a blanket credential reset that ignores the deployment model; use the process-access review to set the rotation scope.

Finally, review who can hold proxy keys and what each preview function does. A connection test that can start a local process belongs behind an execution-grade permission check. The 1.83.7 fix adds that check to these endpoints. Other preview and validation paths deserve the same inspection.