CVE-2026-42271

What is BerriAI LiteLLM?

LiteLLM is an open-source Python proxy and SDK that provides a unified OpenAI-compatible API interface across more than 100 LLM providers (OpenAI, Anthropic, Azure OpenAI, AWS Bedrock, Google Gemini, and others). Organizations deploy LiteLLM as an AI gateway to centralize model access, enforce spend limits, manage API keys, and add observability to AI workloads. Enterprise deployments often store dozens of model provider API keys and credentials within the LiteLLM proxy — making a compromised LiteLLM instance a high-value target for credential theft, AI resource abuse, and lateral movement into connected AI infrastructure.

Overview

CVE-2026-42271 is a command injection vulnerability in LiteLLM's MCP (Model Context Protocol) server test endpoints. Two preview endpoints intended for testing MCP server configurations before saving accepted a full server configuration object — including an OS command to execute — and spawned it as a subprocess without any authorization enforcement beyond a basic API key check. Any valid LiteLLM API key, including low-privilege internal-user keys, was sufficient to trigger arbitrary OS command execution on the host. When chained with CVE-2026-48710 (a Starlette Host header authentication bypass), exploitation is fully unauthenticated — no API key required — with a combined effective severity of CVSS 10.0 Critical.

Affected Versions

Technical Details

Two MCP server preview endpoints in LiteLLM's proxy were exposed with insufficient authorization:

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

These endpoints were designed to test MCP server configurations before saving them. They accepted a full server configuration object in the request body — including command, args, and env fields used for MCP stdio transport. When invoked, the endpoint directly spawned the supplied command as a subprocess under the LiteLLM proxy process's full OS privileges, with no validation or sandboxing. The only gate was a valid API key — a low-privilege internal-user key was sufficient.

Critical chain — CVE-2026-48710 (Starlette BadHost): A Host header validation bypass in Starlette ≤ 1.0.0 completely circumvents API key authentication in LiteLLM when exploited. Combining the two vulnerabilities yields fully unauthenticated RCE: an attacker sends a crafted POST to /mcp-rest/test/connection with a malicious Host header and a command payload in the request body. No API key, no session, no prior access is required. Post-exploitation allows access to all model provider API keys and credentials stored in or accessible to the LiteLLM deployment.

Attack characteristics:

• Attack vector: Network
• Authentication required: Low-privilege API key (CVE-2026-42271 alone); None (chained with CVE-2026-48710)
• User interaction: None
• Impact: Full OS command execution on the LiteLLM proxy host; credential exfiltration from connected AI provider accounts

Discovery

CVE-2026-42271 discovered by researcher "jaydns"; disclosed April 21, 2026 via GitHub Security Advisory GHSA-v4p8-mg3p-g94g. The unauthenticated exploitation chain with CVE-2026-48710 was demonstrated by Horizon3.ai.

Exploitation Context

CISA added CVE-2026-42271 to the KEV catalog on June 8, 2026, citing active exploitation. The unauthenticated chain (with CVE-2026-48710) dramatically lowers the exploitation bar — any internet-exposed LiteLLM proxy on vulnerable versions is effectively unauthenticated RCE with no prerequisites. The primary post-exploitation risk beyond host compromise is theft of model provider API keys (OpenAI, Anthropic, Azure, AWS, etc.) stored in the LiteLLM deployment, which can be used for large-scale AI resource abuse at the victim's expense.

Remediation

1. Upgrade LiteLLM to 1.83.7-stable or later immediately. Version 1.83.7 adds a PROXY_ADMIN role requirement to both /mcp-rest/test/connection and /mcp-rest/test/tools/list.
2. Upgrade Starlette to 1.0.1 or later to close the authentication bypass chain (CVE-2026-48710). Both fixes are required to fully remediate the unauthenticated RCE path.
3. Restrict network access: Do not expose LiteLLM proxy endpoints — especially /mcp-rest/ — to the public internet. Apply firewall or reverse proxy controls to limit access to trusted source IPs.
4. Rotate all model provider API keys stored in or accessible from the LiteLLM deployment, as they may have been exfiltrated during active exploitation.
5. Review access logs for unexpected calls to /mcp-rest/test/connection or /mcp-rest/test/tools/list to determine whether exploitation occurred prior to patching.