A critical vulnerability chain affecting LiteLLM has been identified, enabling unauthenticated remote code execution (RCE) on exposed servers.
Tracked as CVE-2026-42271 and chained to CVE-2026-48710, the issue allows attackers to bypass authentication controls and execute arbitrary system commands, posing a severe risk to AI infrastructure that relies on LiteLLM deployments.
LiteLLM Vulnerability
CVE-2026-42271 is a command injection flaw in LiteLLM’s MCP (Model Context Protocol) server test endpoints, specifically “/mcp-rest/test/connection” and “/mcp-rest/test/tools/list.”
These endpoints are designed to accept full server configurations, including executable commands, arguments, and environment variables for stdio-based transport.
When invoked, LiteLLM spawns these commands as subprocesses on the host system. Initially, the vulnerability was considered low risk because access to these endpoints required a valid proxy API key.
However, researchers at Horizon3.ai demonstrated that this protection can be completely bypassed when combined with CVE-2026-48710, a Starlette framework vulnerability involving improper Host header validation.
The flaw, often referred to as the “BadHost” bypass, affects Starlette versions up to 1.0.0 and enables attackers to manipulate Host headers to circumvent authentication mechanisms in affected applications.
When LiteLLM deployments rely on vulnerable Starlette versions, attackers can exploit this weakness to reach the MCP test endpoints without credentials.
This chained exploitation results in full unauthenticated RCE, allowing attackers to execute arbitrary commands under the privileges of the LiteLLM proxy process. Successful attacks can expose sensitive data, including model provider credentials, API keys, and environment secrets stored within the proxy.
Additionally, threat actors may leverage compromised instances to pivot laterally across connected AI systems, potentially impacting downstream services integrated with the gateway.
Security researchers have assigned the vulnerability chain a CVSS score of 10.0, indicating critical severity. The affected versions include LiteLLM releases from 1.74.2 through 1.83.6, particularly in environments where Starlette dependencies remain at or below version 1.0.0.
Indicators of compromise include unexpected subprocess executions triggered via MCP endpoints, suspicious HTTP requests targeting test routes, anomalous Host header values, and evidence of unauthorized command execution on the host. Organizations should closely monitor logs for these signals to detect potential exploitation attempts.
Indicators of Compromise
| Indicator | Type | Description |
| Unexpected subprocess execution | Behavioral | Commands spawned through LiteLLM MCP test endpoints |
| Requests to /mcp-rest/test/connection | HTTP Activity | Suspicious use of testing functionality |
| Requests to /mcp-rest/test/tools/list | HTTP Activity | Potential exploitation attempts |
| Unusual Host header values | Network Indicator | Potential abuse of CVE-2026-48710 authentication bypass |
| Unauthorized command execution | Host Activity | Evidence of successful exploitation and host compromise |
Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.
To mitigate the risk, users are strongly advised to upgrade LiteLLM to version 1.83.7 or later and ensure Starlette is updated to version 1.0.1 or newer. Where immediate patching is not feasible, administrators should restrict access to MCP test endpoints, enforce network segmentation, rotate sensitive credentials, and audit logs for suspicious activity.
The vulnerabilities were disclosed in stages: CVE-2026-42271 was reported in April 2026, followed by a patch release in May. The Starlette “BadHost” issue was publicly detailed later that month, and by June 2026, Horizon3.ai confirmed the full unauthenticated exploitation chain.
This development underscores the growing security risks in AI infrastructure and the importance of securing framework dependencies alongside application logic.
Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.
