Cloud Security

LiteLLM RCE Chain CVSS 10.0: Your AI Keys Are the Prize

June 10, 2026 · 7 min read · By William

LiteLLM CVE-2026-42271: CVSS 10.0 RCE Chain

CISA added a command injection flaw in the LiteLLM AI gateway to its Known Exploited Vulnerabilities catalog on June 9, 2026, confirming active exploitation in the wild. The vulnerability, tracked as CVE-2026-42271 (CVSS 8.7), already carried serious impact on its own — any authenticated user could execute arbitrary commands on the proxy host. But researchers at Horizon3.ai demonstrated that chaining it with a Starlette host header bypass (CVE-2026-48710) eliminates the authentication requirement entirely, producing a CVSS 10.0 unauthenticated remote code execution chain. If you run self-hosted LiteLLM, the clock is already running.

This is the third time in three months that LiteLLM has been in the crosshairs. In March, the TeamPCP group poisoned PyPI with malicious LiteLLM packages. In April, CVE-2026-42208, a pre-auth SQL injection flaw (CVSS 9.3), was exploited within 36 hours of public disclosure. The pattern is clear: LiteLLM occupies a position of concentrated trust as a credential aggregator for AI infrastructure, and threat actors understand exactly what that position is worth. Stolen credentials remain the top breach vector across all industries, making credential-rich targets like LiteLLM particularly attractive.

LiteLLM: The Credential Aggregator

LiteLLM is an open-source proxy that normalises access to multiple large language model APIs — OpenAI, Anthropic, Mistral, Google — through a single OpenAI-compatible interface. Organisations deploy it as a self-hosted gateway to centralise API key management, enforce rate limits, and avoid vendor lock-in. That architecture also means a single compromised instance exposes credentials for every connected model provider at once.

As Help Net Security noted, LiteLLM can be used either as a Python SDK integrated directly into applications or as a standalone proxy server. The proxy mode is where the damage compounds: the gateway stores provider API keys, routing configurations, and often organisation-wide secrets. It sits precisely where attackers want to be.

Command Injection via MCP Endpoints

CVE-2026-42271 affects LiteLLM versions 1.74.2 through 1.83.6. The vulnerability lies in two Model Context Protocol (MCP) server test endpoints designed to let users preview a server configuration before saving it:

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

Both endpoints accepted a complete server configuration in the request body, including the command, args, and env fields used by the stdio transport. When invoked with a stdio configuration, LiteLLM spawned the supplied command as a subprocess on the proxy host with the full privileges of the proxy process — no validation, no sandboxing, no role check.

According to The Hacker News, any authenticated user holding even a low-privilege internal-user API key could send a crafted POST request and execute arbitrary commands on the host. The fix in version 1.83.7 restricts both test endpoints to the PROXY_ADMIN role, consistent with the save endpoint.

The BadHost Chain: Dropping Auth Entirely

On its own, CVE-2026-42271 was limited by the authentication gate — serious, but scoped to environments where an attacker already held a valid API key. Horizon3.ai changed that calculus by chaining it with CVE-2026-48710 (CVSS 6.5), a host header validation bypass in Starlette — the lightweight ASGI framework that LiteLLM uses for HTTP handling.

Starlette versions 1.0.0 and below fail to validate the Host header correctly, a flaw dubbed “BadHost.” By crafting a request with a manipulated Host header, an attacker can bypass LiteLLM’s authentication middleware entirely. The combined chain — BadHost to drop auth, then command injection to get RCE — requires zero credentials and achieves full code execution on the proxy host. Horizon3.ai assessed the chained exploit at CVSS 10.0.

Successful exploitation gives attackers the ability to execute arbitrary commands, access all model provider credentials stored by the proxy, steal API keys and secrets, move laterally into connected AI infrastructure, and compromise downstream systems integrated with the gateway.

Exploitation Timeline and Scope

CybelAngel’s analysis notes the gap between disclosure and active exploitation was approximately 50 days. CVE-2026-42271 was publicly disclosed on April 20, 2026, and CISA added it to the KEV catalog on June 9, 2026, citing confirmed exploitation. CISA has directed US federal civilian agencies to address the flaw by June 22, 2026.

The scope of the exploitation campaign remains unclear. CISA’s KEV listing confirms in-the-wild activity but provides no details on threat actor identity, victim profiles, or whether the BadHost chain is being leveraged alongside the base command injection. What is confirmed is that LiteLLM is being systematically targeted as a high-value asset in AI infrastructure.

Remediation: Two Packages, Both Critical

Patching is not optional at this point. The remediation requires updating two components:

Upgrade LiteLLM to version 1.83.7 or later. This adds PROXY_ADMIN role enforcement on the MCP test endpoints and updates dependency constraints for Starlette.
Upgrade Starlette to version 1.0.1 or later. This patches the BadHost header validation bypass (CVE-2026-48710) that enables the unauthenticated chain.

If immediate patching is not feasible, deploy these compensating controls now:

Block access to /mcp-rest/test/connection and /mcp-rest/test/tools/list at your reverse proxy or API gateway.
Restrict network access to LiteLLM instances to trusted internal segments only.
Rotate all credentials and API keys stored by the proxy.
Review logs for unusual Host header values and unexpected subprocess execution events.

Horizon3.ai has published a list of indicators of compromise, including unexpected subprocess execution on the LiteLLM host, HTTP requests to the MCP test endpoints, unusual Host header values, and evidence of unauthorised command execution.

LiteLLM as a Recurring Target

This vulnerability does not exist in isolation. LiteLLM has been hit three times in rapid succession, and each incident targeted the same asset: credentials.

Incident	Date	Vector	Target
TeamPCP supply chain attack	March 2026	Malicious PyPI packages	Secrets, tokens, credentials
CVE-2026-42208 SQL injection	April 2026	Pre-auth SQLi (CVSS 9.3)	Application database secrets
CVE-2026-42271 + BadHost chain	June 2026	Command injection + auth bypass (CVSS 10.0)	Host RCE, all stored API keys

Each attack iteration raises the severity and broadens the attack surface. The SQL injection was exploited within 36 hours of disclosure. The command injection chain achieved CVSS 10.0 unauthenticated RCE. As SC Media quoted researchers: “LiteLLM sits in a position of concentrated trust.” Different route, same destination — every time, the goal is credential exfiltration.

Broader Implications for AI Gateway Security

The LiteLLM situation is a preview of what every organisation deploying self-hosted AI gateways will face. These components sit at a trust boundary that did not exist two years ago: they hold production credentials for every AI provider an organisation uses, they accept and route requests from multiple internal services, and they run as middleware that is often deployed with less security scrutiny than the applications they serve. The security risks in Anthropic’s Claude Skills framework exposed a similar pattern — AI tooling layers that accumulate trust without proportional security controls.

Security teams should audit their AI infrastructure for the following:

Exposed management endpoints. Test, debug, and preview endpoints have no business being accessible from untrusted networks. Enforce role-based access and network segmentation.
Credential storage practices. If your AI gateway stores provider API keys in plaintext or in a readily accessible database, a single compromise cascades to every connected service.
Dependency chain hygiene. The BadHost bypass lives in Starlette, not LiteLLM itself. Your vulnerability scanning must cover the full dependency tree, not just the top-level package.
Supply chain integrity. Package managers like PyPI remain a proven attack vector — the Miasma worm that recently compromised 73 Microsoft GitHub repos demonstrated the same pattern at scale. Pin versions, verify checksums, and monitor for typosquatting.