Critical LiteLLM RCE Vulnerability Under Active Exploitation

Key Takeaways

• A critical remote code execution (RCE) vulnerability in LiteLLM, an open-source AI gateway proxy, is under active exploitation.
• The flaw, rated CVSS 10.0, allows unauthenticated attackers to execute arbitrary code due to a chained exploit involving command injection and an authentication bypass.
• Affected LiteLLM versions range from 1.74.2 to 1.83.6, particularly when combined with Starlette versions 1.0.0 or earlier.
• A patch is available: upgrade LiteLLM to 1.83.7+ and Starlette to 1.0.1+.

Threat actors are actively exploiting a severe vulnerability within LiteLLM, a widely adopted open-source proxy for AI applications, enabling unauthenticated remote code execution (RCE) on affected systems. This critical attack vector, confirmed by security researchers at Horizon3.ai, stems from a combination of two distinct Common Vulnerabilities and Exposures (CVEs), culminating in a CVSS score of 10.0, indicating maximum severity and requiring no credentials for successful exploitation.

The Chained Vulnerability Explained

At the core of this critical flaw is CVE-2026-42271, a command injection vulnerability present in LiteLLM’s Model Context Protocol (MCP) server test endpoints. Specifically, the POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list endpoints were found to accept full server configurations, including commands, arguments, and environment variables, subsequently spawning this input as a subprocess on the host system.

Initially, when disclosed on April 20, 2026, the impact of this command injection was considered limited, as it was believed to require a valid proxy API key for access. However, this assumption was disproved when Horizon3.ai researchers identified a chain with CVE-2026-48710. This second vulnerability is a Starlette “BadHost” Host Header validation bypass, impacting Starlette versions 1.0.0 and earlier.

By leveraging the Starlette authentication bypass through a manipulated HTTP Host header, attackers can completely circumvent LiteLLM’s API key requirement. This allows unauthenticated remote code execution commands to be run with the same privileges as the LiteLLM proxy process, requiring no prior authentication or API key.

LiteLLM versions from 1.74.2 through 1.83.6 are vulnerable, particularly in deployments where the dependency tree includes Starlette versions 1.0.0 or older.

Impact of LiteLLM RCE Vulnerability

Successful exploitation of this chained vulnerability grants threat actors extensive control over AI infrastructure. Once code execution is achieved, attackers can:

• Execute arbitrary operating system commands on the host running LiteLLM.
• Exfiltrate API keys and credentials for model providers stored by the proxy.
• Access sensitive secrets and environment variables within the proxy process.
• Perform lateral movement into connected AI infrastructure and downstream systems.

Given LiteLLM’s widespread use in routing and managing API calls to large language models (LLMs) from providers like OpenAI, Anthropic, and Azure, a compromise at the gateway level could lead to a significant exposure across the broader AI supply chain.

Indicators of Compromise

Security teams should vigilantly monitor for the following signs that indicate potential exploitation activity:

• Unusual or unexpected subprocesses originating from the LiteLLM process.
• HTTP requests specifically targeting the /mcp-rest/test/connection or /mcp-rest/test/tools/list endpoints.
• Malformed or suspicious Host header values observed in proxy logs.
• Evidence of unauthorized command execution events on the host system.

What You Should Do

Organizations must prioritize immediate action to mitigate this critical vulnerability. It is imperative to upgrade LiteLLM to version 1.83.7 or later and ensure Starlette is updated to version 1.0.1 or later. If immediate patching is not feasible, implement the following interim measures:

• Block all external access to the MCP test endpoints.
• Restrict the proxy’s network access to only trusted segments.
• Rotate all credentials and API keys stored by the proxy.
• Conduct thorough reviews of logs for anomalous Host header values and subprocess events.

Given the active exploitation of this vulnerability in the wild, patching should be treated as an emergency priority for any organization operating a self-hosted LiteLLM deployment.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.