CVE-2026-42271: LiteLLM Command Injection in MCP Endpoints Gives Any User Shell Access

Background

LiteLLM is an open-source AI gateway proxy developed by BerriAI that provides a unified API interface for over a hundred large language model providers — OpenAI, Anthropic, Google, Azure OpenAI, Cohere, and others. Organisations deploy it to centralise LLM access, enforce rate limits and spend controls, and manage API key distribution across development teams. Because LiteLLM sits at the intersection of internal services and every LLM provider an organisation uses, a compromise of the proxy yields credentials for all of them simultaneously.

CVE-2026-42271 is a command injection vulnerability introduced in LiteLLM’s Model Context Protocol (MCP) integration. MCP is an emerging standard for connecting AI models with external tools and data sources; LiteLLM’s MCP support — at the time of the vulnerability, a preview feature — includes a pair of test endpoints that accept MCP server configuration objects from callers. These endpoints spawn subprocesses to test MCP server connections using the stdio transport model, and they do so with no meaningful access control and no validation of the provided executable path.

CISA added CVE-2026-42271 to the Known Exploited Vulnerabilities catalogue on 8 June 2026 with a remediation deadline of 22 June 2026 for federal agencies. The fixed release is v1.83.7-stable.

Technical Mechanism

The vulnerability is located in two MCP test endpoints introduced in LiteLLM’s MCP integration:

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

These endpoints accept a full MCP server configuration object — including an executable command, argument list, and environment variables — to test whether a configured MCP server is reachable via the stdio transport model. The stdio transport model for MCP works by spawning an external process and communicating over its standard input and output. LiteLLM’s implementation calls subprocess.Popen with the caller-supplied command field directly:

# Vulnerable pattern — command taken directly from user input
process = subprocess.Popen(
    [config["command"]] + config["args"],
    env=config.get("env", {}),
    stdin=subprocess.PIPE,
    stdout=subprocess.PIPE
)

There is no allowlist of executable paths, no sandboxing, and critically, no role-based access control on the endpoints themselves. Any caller presenting a valid API key — regardless of privilege level — can call these endpoints. Internal-user keys, which are commonly distributed across development teams as a convenience, are sufficient. An attacker supplying /bin/bash as the command with a -c "..." argument list obtains shell access on the proxy host.

The subprocess runs with the same OS permissions as the LiteLLM process itself. In many deployments, particularly Docker containers without privilege dropping, LiteLLM runs as root.

A related vulnerability, CVE-2026-48710, is a Host Header validation bypass in Starlette ≤1.0.0 — LiteLLM’s underlying web framework. This bypass allows an attacker to circumvent LiteLLM’s authentication layer entirely. When combined with CVE-2026-42271, the chain produces unauthenticated RCE accessible to any network client that can reach the proxy port.

The v1.83.7-stable fix adds proper authorization checks to the MCP test endpoints, restricting them to admin-tier keys, and introduces validation on the provided command path.

Real-World Exploitation Evidence

CISA’s KEV catalogue entry for CVE-2026-42271 confirms active exploitation. Horizon3.ai published a technical analysis covering both the standalone authenticated variant and the unauthenticated chain with CVE-2026-48710, including proof-of-concept request structures.

The exploitation context for CVE-2026-42271 sits within a pattern of serial security incidents affecting LiteLLM in 2026. In March 2026, the TeamPCP threat actor compromised LiteLLM PyPI packages v1.82.7 and v1.82.8 in a supply chain attack, injecting malicious code that exfiltrated LLM API keys from affected deployments. In April 2026, CVE-2026-42208 — a critical SQL injection in LiteLLM’s authentication path — was disclosed and exploited within 36 hours of publication. CVE-2026-42271 marks LiteLLM’s third significant security incident in 2026.

The exploitation scenario of most immediate concern for production deployments: an attacker holding any valid internal-user key — or bypassing authentication entirely with the CVE-2026-48710 chain — gains shell access to the proxy host, then pivots to environment variables and the proxy database to harvest every LLM provider API key the organisation has configured. No specific ransomware groups have been publicly attributed to CVE-2026-42271 exploitation at time of writing.

Impact Assessment

CVE-2026-42271 carries a CVSS 3.1 base score of 8.8 (HIGH) for the standalone variant:

• Attack vector: Network (reachable from any client with network access to the proxy port)
• Attack complexity: Low
• Privileges required: Low (any valid API key, including low-privilege internal-user keys, is sufficient)
• User interaction: None
• Scope: Unchanged
• Impact: High confidentiality, high integrity, high availability — full host compromise via arbitrary command execution

The chained attack combining CVE-2026-42271 with CVE-2026-48710 (Starlette Host Header bypass) scores 10.0 (CRITICAL) and removes the authentication prerequisite entirely.

The practical consequence of exploitation extends beyond the immediate host. LiteLLM’s architectural role as a centralised AI gateway means a single compromise yields API keys for every LLM provider the organisation has configured — OpenAI, Anthropic, Google, Azure OpenAI, and others. Provider API key theft enables continued LLM API usage on the victim’s account, potentially incurring significant financial charges. Keys used internally for sensitive applications may also expose system prompts, user conversation data, and custom model configuration.

Affected Versions

Deployments running LiteLLM as a Docker container, Kubernetes pod, or bare-metal service are all affected. Cloud-managed deployments that pin versions are affected if the v1.83.7-stable update has not been applied.

Remediation Steps

Upgrade to LiteLLM v1.83.7-stable or later. This is the only complete remediation. The fix is not backported to earlier branches.

# pip
pip install litellm==1.83.7

# Docker
docker pull ghcr.io/berriai/litellm:main-v1.83.7-stable

Review the GitHub release notes for v1.83.7-stable for additional security hardening changes included in the same release, including fixes for path traversal in skill archive extraction and improvements to token lookup query parameterisation.

If immediate upgrade is not possible:

Restrict network access to the proxy. The MCP test endpoints are only reachable if an attacker can reach the LiteLLM HTTP port. VPC firewall rules or network policies limiting proxy access to authorised client IPs eliminate the external attack surface.

Audit and rotate API key distribution. Revoke or rotate internal-user keys that are broadly distributed. The standalone variant requires any valid key — reducing the number of holders reduces exposure.

Pin Starlette to ≥1.1.0. This prevents the unauthenticated chain. If LiteLLM is deployed via Docker, inspect the container image for the Starlette version. If via pip, run pip show starlette to confirm the installed version.

Following any patch or investigation: rotate all LLM provider API keys configured in the proxy. Given the March 2026 supply chain compromise and the serial vulnerability pattern, assume any key that has been in LiteLLM’s possession since March 2026 may have been exfiltrated.

Detection Guidance

Access logs: Filter LiteLLM proxy HTTP access logs for POST requests to /mcp-rest/test/connection or /mcp-rest/test/tools/list. Legitimate use of these endpoints is rare outside active MCP integration development. Any such request from an unexpected source IP or API key should be treated as a potential exploitation attempt and investigated immediately.

Process monitoring: Monitor the LiteLLM process tree for unexpected child processes. On Linux hosts, auditd rules on execve syscalls originating from the LiteLLM process will capture subprocess spawning. In Kubernetes environments, Falco or equivalent runtime security tooling can alert on unexpected process creation within the LiteLLM pod.

Sigma rule — LiteLLM subprocess execution:

title: LiteLLM MCP Endpoint Subprocess Execution
logsource:
  category: process_creation
detection:
  selection:
    ParentImage|contains: 'python'
    ParentCommandLine|contains: 'litellm'
    Image|endswith:
      - '/bash'
      - '/sh'
      - '/cmd.exe'
  condition: selection
falsepositives:
  - Legitimate MCP server testing by developers — correlate with expected source IPs and time windows
level: high

Environment variable and credential audit: Following any suspicious activity, audit LiteLLM’s environment variables and the proxy database for signs of key extraction. All LLM provider API keys stored in the proxy should be rotated if compromise is suspected or cannot be ruled out.

Starlette version verification: Run pip show starlette or inspect the container image to confirm the Starlette version. Any deployment with Starlette ≤1.0.0 should be treated as at risk for unauthenticated exploitation and remediated on the same timeline as the LiteLLM upgrade.

Timeline

References

• LiteLLM GitHub — v1.83.7-stable release notes
• Horizon3.ai — Technical analysis of CVE-2026-42271 and CVE-2026-48710 chain
• CISA Known Exploited Vulnerabilities Catalogue
• NVD — CVE-2026-42271
• NVD — CVE-2026-48710 (Starlette Host Header bypass)