LiteLLM, a widely deployed open-source AI gateway, is affected by a critical exploit chain that allows unauthenticated attackers to execute arbitrary commands on vulnerable hosts. CISA added CVE-2026-42271 to its Known Exploited Vulnerabilities (KEV) catalog on June 9, 2026, confirming active exploitation in the wild. The Qilin ransomware group has been linked to exploitation activity.
What makes this especially dangerous is the chain: CVE-2026-42271 on its own required a valid API key. When combined with CVE-2026-48710, a Host Header bypass in the Starlette framework, attackers can sidestep authentication entirely.
What is CVE-2026-42271?
CVE-2026-42271 is a command injection vulnerability in LiteLLM’s Model Context Protocol (MCP) server test endpoints. Two endpoints — POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list — were designed to let users preview an MCP server configuration before saving it. Both accepted a full server configuration in the request body, including command, args, and env fields. When called, LiteLLM spawned the supplied command as a subprocess on the proxy host with full process privileges and no sandboxing.
Originally, the vulnerability was considered limited in severity because the endpoints required a valid proxy API key. That changed when CVE-2026-48710, a Host Header bypass in the Starlette framework, was chained with it, enabling unauthenticated remote code execution with no credentials required.
What is CVE-2026-48710 (“BadHost”)?
CVE-2026-48710 is a Host Header validation bypass vulnerability in Starlette, the lightweight ASGI framework that sits in LiteLLM’s dependency tree. By manipulating the HTTP Host header in a specific way, attackers can bypass LiteLLM’s authentication controls entirely in deployments running Starlette version 1.0.0 or earlier. The result is that the vulnerable MCP test endpoints become reachable with no API key and no credentials at all.
What Can Attackers Do After Exploiting CVE-2026-42271?
Because LiteLLM sits centrally between applications and multiple AI providers, a single compromised instance can expose an organization’s entire AI provider stack in one operation. Successful exploitation of the chained vulnerability enables attackers to:
Execute arbitrary OS commands on the LiteLLM proxy host
With the full privileges of the proxy process, effectively giving them the same level of access as a system administrator on the host machine.
Steal all stored AI provider credentials in a single operation
Including API keys for OpenAI, Anthropic, Azure OpenAI, AWS Bedrock, and Google Gemini. Production LiteLLM deployments hold all configured provider credentials in one place, making a single compromised instance enough to expose the entire AI provider stack.
Access environment variables and internal secrets
Stored by the proxy, which may include database connection strings, internal service tokens, and other sensitive configuration data beyond AI provider keys.
Move laterally into connected applications and internal infrastructure
Using the proxy’s network position and stored credentials as a launchpad to reach backend systems that would otherwise be inaccessible from outside the network.
Compromise downstream systems integrated with the gateway
Potentially affecting every application that routes AI requests through the LiteLLM instance, multiplying the blast radius well beyond the initial point of entry.
Who Is Affected
Organizations running self-hosted LiteLLM versions 1.74.2 through 1.83.6 where the dependency tree includes Starlette version 1.0.0 or earlier are at full unauthenticated RCE risk. Sectors at heightened exposure include technology, financial services, healthcare, and research institutions that have adopted LiteLLM as a central AI gateway. Attackers have been observed using automated scanning to identify internet-facing instances at scale.
Attack Timeline
| Date | Event |
|---|---|
| April 20, 2026 | CVE-2026-42271 disclosed as an authenticated command injection vulnerability |
| May 8, 2026 | LiteLLM releases v1.83.7 with authorization controls and updated Starlette dependency |
| May 26, 2026 | CVE-2026-48710 (“BadHost”) publicly disclosed — Host Header bypass affecting Starlette ≤1.0.0 |
| June 1, 2026 | Researchers confirm the chained unauthenticated RCE path |
| June 9, 2026 | CISA adds CVE-2026-42271 to the KEV catalog; Qilin ransomware group linked to exploitation |
| June 22, 2026 | Federal agency remediation deadline under BOD 22-01 |
How to Detect CVE-2026-42271 and CVE-2026-48710 Exploitation
Detecting exploitation of this chain requires reviewing both network-level and host-level logs for signs of unauthorized activity. Security teams should look for:
- HTTP POST requests targeting
/mcp-rest/test/connectionor/mcp-rest/test/tools/listin proxy and web server access logs, especially from IP addresses outside trusted network segments or at unusual hours inconsistent with normal developer activity. - Unusual or malformed Host header values in incoming requests to the LiteLLM instance, which are a direct indicator of the Starlette “BadHost” authentication bypass being attempted or successfully used to skip API key validation.
- Unexpected subprocess execution spawned by the LiteLLM process, particularly shells such as
shorbash, interpreters such aspythonornode, or network tools such ascurl,wget, ornc, none of which should appear as child processes of the proxy under normal operating conditions. - Outbound network connections originating from LiteLLM subprocesses to untrusted or unrecognized external destinations, which indicate that an attacker has achieved command execution and is likely staging credential exfiltration or establishing persistence.
- Unauthorized access to or modification of stored credentials and API keys, including any anomalous read activity on the LiteLLM configuration file or environment variable store, since credential theft is typically the first objective once command execution is achieved.
How to Fix CVE-2026-42271: Patch and Remediation Steps
The most effective remediation is to patch both affected components immediately. Both upgrades are required — addressing only one does not close the full exploit chain.
Upgrade LiteLLM to version 1.83.7 or later
This version introduces role-based authorization controls on the MCP test endpoints, restricting them to PROXY_ADMIN users only and eliminating the ability for low-privilege API keys to trigger subprocess execution.
Upgrade Starlette to version 1.0.1 or later
This closes the “BadHost” Host Header validation bypass used in CVE-2026-48710, removing the authentication circumvention path that transforms the vulnerability from authenticated to unauthenticated RCE.
Block the vulnerable endpoints at your reverse proxy or API gateway
If immediate patching is not feasible, deny all external access to POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list as an interim control while the upgrade is prepared and tested.
Rotate all credentials and API keys stored by the proxy
As a precautionary measure, including AI provider keys for OpenAI, Anthropic, Azure, and AWS, as well as any internal service tokens or secrets accessible to the LiteLLM process. This should be done regardless of whether active exploitation has been confirmed.
Conduct a post-patch compromise assessment
Review logs for unexpected subprocess activity, unusual Host header patterns, and anomalous outbound connections that may have occurred before the patch was applied. Active exploitation was confirmed weeks before many organizations would have been alerted to the risk, making a retrospective log review essential even if no immediate signs of compromise are visible.
How AppTrana Helps
AppTrana provides coverage against exploitation attempts targeting CVE-2026-42271. For CVE-2026-48710, AppTrana blocks requests with malformed Host header values consistent with the Starlette authentication bypass by default, with no additional configuration required.
Stay tuned for more relevant and interesting security articles. Follow Indusface on Facebook, Twitter, and LinkedIn.