← Back to blog AdvisoryCritical

LiteLLM MCP-Preview Command Injection Chained to Unauthenticated RCE - CVE-2026-42271

Q: What is CVE-2026-42271 in LiteLLM?

CVE-2026-42271 is a command injection flaw rated CVSS 8.7 in two LiteLLM endpoints used to preview an MCP server before saving it: POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list. Both accept a full MCP server configuration in the request body, including the command, args, and env fields the stdio transport uses to launch a process. Because LiteLLM runs that configuration to test the connection, any authenticated user can supply a crafted command and run arbitrary commands on the gateway host. The flaw is fixed in LiteLLM 1.83.7, and CISA added it to the Known Exploited Vulnerabilities catalog on June 8, 2026 with a federal remediation deadline of June 22, 2026.

Q: How does the chain with CVE-2026-48710 reach unauthenticated RCE?

On its own, CVE-2026-42271 requires an authenticated user. Horizon3.ai chained it with CVE-2026-48710, a Starlette host-header validation bypass tracked as the BadHost issue, to skip authentication entirely. By sending a request that defeats Starlette's host validation, an attacker reaches the MCP-preview endpoints without valid credentials and triggers the command injection, achieving unauthenticated remote code execution against an exposed LiteLLM deployment. Closing the chain requires both updates: LiteLLM to 1.83.7 or later and Starlette to 1.0.1 or later. Updating only one leaves either the authenticated injection or the auth bypass in place.

Q: What can an attacker do after exploiting CVE-2026-42271?

LiteLLM is an LLM gateway that holds model-provider credentials and proxies traffic to back-end models. Once an attacker runs commands on the gateway host, they can read model-provider credentials, siphon stored API keys and secrets, and move laterally into connected AI infrastructure the gateway can reach. Because the gateway is a central chokepoint, a single compromised host can expose keys for every model and account routed through it. That is why this sits in the CISA KEV catalog with active exploitation cited, and why secret hygiene on the gateway and an inventory of which endpoints reach it both matter alongside the patch.

Q: How does Anomity reduce exposure to this class of flaw?

Anomity inventories every MCP server an endpoint is configured to reach and every gateway and CLI it talks to, as part of the eight AI artifact types it tracks per endpoint, and records metadata such as the LiteLLM client version and the stdio command, args, and env fields used to launch a server. On agents that expose a hook, for example the PreToolUse event in Claude Code, it evaluates each tool call and returns allow, deny, or log before the call runs, so a call routed through an untrusted MCP target is stopped at the boundary. Every decision and configuration change lands in a queryable 90-day audit trail routed to your SIEM. Secrets are redacted on the endpoint, so stored API keys never leave it in the clear.

Anomity Research Anomity Threat Research · Jun 9, 2026 · 6 min read

LLM Gateways & Proxies·Critical·CVE-2026-42271 (chained with CVE-2026-48710)·Jun 9, 2026

Affected LiteLLM before 1.83.7 (RCE chain requires Starlette <= 1.0.0); update LiteLLM 1.83.7+ and Starlette 1.0.1+

CVE-2026-42271 is a LiteLLM RCE - a command injection flaw rated CVSS 8.7 in the gateway's MCP-preview endpoints, chained by researchers into unauthenticated remote code execution. CISA added it to the Known Exploited Vulnerabilities catalog on June 8, 2026 with active exploitation cited. This advisory covers what was disclosed, why a LiteLLM RCE lands on the agentic-endpoint layer, and how to inventory and govern the MCP configurations and gateways your endpoints reach.

What happened

CVE-2026-42271 is a command injection flaw rated CVSS 8.7 in LiteLLM, the open-source LLM gateway. It lives in two endpoints used to preview an MCP server before saving it: POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list. Both accept a full MCP server configuration in the request body, including the command, args, and env fields that the stdio transport uses to launch a process. LiteLLM runs that configuration to test the connection, so any authenticated user can supply a crafted command and run arbitrary commands on the gateway host. This is the same stdio launch primitive behind the broader STDIO by-design command execution class - here reachable straight from a gateway API.

Horizon3.ai chained CVE-2026-42271 with CVE-2026-48710, the Starlette host-header validation bypass known as the BadHost issue, to skip authentication entirely and reach the MCP-preview endpoints with no valid credentials - turning an authenticated injection into unauthenticated remote code execution against exposed deployments. Successful exploitation lets an attacker read model-provider credentials, siphon stored API keys and secrets, and move laterally into connected AI infrastructure. The fix requires updating LiteLLM to 1.83.7 or later and Starlette to 1.0.1 or later; the RCE chain depends on Starlette 1.0.0 or earlier. CISA added CVE-2026-42271 to its KEV catalog on June 8, 2026, with a federal remediation deadline of June 22, 2026. This is the second LiteLLM pre-auth-class issue in this wave, alongside the LiteLLM pre-auth SQL injection tracked as CVE-2026-42208.

Why this is an agentic-endpoint risk

An LLM gateway is not just network plumbing. LiteLLM is the chokepoint an AI agent routes model calls through, and the MCP-preview endpoints exist precisely so a user can wire up an MCP server - a tool source the agent then uses. The injected payload travels through the command, args, and env fields of an MCP server definition, which is exactly the AI artifact layer that bottom-up adoption fills. A developer pastes an MCP config to test it, and the gateway launches it; the same fields meant to start a tool server become the execution vector.

This exposure is hard to see from the controls you already run. The MCP configuration sits in a request body and a gateway database, not in a file EDR watches; the network sees encrypted API traffic to a gateway that is supposed to be reachable; and DLP sees nothing at rest. MCP servers, the gateways that broker them, and the secrets those gateways hold are part of the eight AI artifact types adopted faster than security can track - the dynamic that makes AI agents and MCP servers the new shadow IT. The question is not only whether a given LiteLLM build is patched; it is which endpoints reach which gateways, what MCP configurations those gateways will launch, and which tool calls are allowed to run.

How Anomity surfaces and governs it

Updating LiteLLM to 1.83.7 and Starlette to 1.0.1 closes this specific chain, but the durable control is to treat the MCP configuration and the gateway connection as a trust boundary and govern which servers endpoints reach and which tool calls run. Anomity does that in three steps.

First, inventory. Anomity inventories every MCP server an endpoint is configured to reach and every gateway and CLI it talks to, as part of the eight AI artifact types it tracks per endpoint. It captures the configuration metadata - including the LiteLLM client version and the command, args, and env fields a stdio MCP definition would launch - so you can find LiteLLM builds before 1.83.7 and MCP definitions that would run an unexpected command. Metadata only: secrets such as model-provider keys are redacted on the endpoint before anything leaves it.

Second, decide at the hook. On agents that expose a hook - for example, the PreToolUse event in Claude Code - Anomity evaluates each tool call against your policy and returns allow, deny, or log before the call runs. A tool call routed through an MCP server or gateway that is not on your trust list can be denied at the boundary, which is exactly the control runtime governance provides while a vulnerable LiteLLM build is still being rolled forward across the fleet.

Third, keep the record. Every decision, and every added, changed, or removed MCP server, gateway target, or secret reference, lands in a queryable 90-day audit trail, and decisions route to SIEM, Slack, email, or Jira. When a KEV entry like CVE-2026-42271 lands, you can answer which endpoints ran the affected LiteLLM versions and what MCP configurations they were allowed to launch - from a record, not a guess. Anomity is SOC 2 Type II and complements your Network, EDR, DLP, and GRC tooling.

You can't govern what you can't see.The Anomity principle

What to check across your fleet

Inventory every LiteLLM deployment and record the version; flag anything before 1.83.7 and update to 1.83.7 or later, and update Starlette to 1.0.1 or later to break the unauthenticated chain.
Confirm the MCP-preview endpoints POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list are not reachable from untrusted networks, and treat any LiteLLM exposed to the internet as a KEV-priority item ahead of the June 22, 2026 deadline.
Enumerate the MCP server configurations stored on or reachable through each gateway, and review the command, args, and env fields for definitions that would launch an unexpected process.
Rotate model-provider credentials and stored API keys held by any LiteLLM instance that was internet-exposed while running a version before 1.83.7, since exploitation siphons keys and secrets.
Confirm high-risk tool calls routed through a gateway or MCP server are evaluated at the agent hook with allow/deny/log, so a call through an untrusted target is stopped before it runs.
Verify every gateway target, MCP definition, and configuration change is written to a 90-day audit trail and routed to your SIEM.
Cross-reference this inventory against the sibling LiteLLM pre-auth SQL injection advisory to find gateways exposed to more than one pre-auth path.

CVE-2026-42271 is a reminder that the LLM gateway is part of the agentic attack surface, not separate from it: the same MCP fields meant to launch a tool server can launch an attacker's command, and a Starlette host-header bypass removes the login in front of it. Update LiteLLM to 1.83.7 and Starlette to 1.0.1 before the June 22, 2026 KEV deadline, then inventory which gateways your endpoints reach and govern the resulting tool calls at the hook. For the full gateway attack surface, trust tiers, and the disclosures this sits within, see the pillar guide on securing LLM gateways and proxies. To see Anomity inventory and govern the gateway and MCP layer across your fleet, request early access.

Frequently asked questions

What is CVE-2026-42271 in LiteLLM?

CVE-2026-42271 is a command injection flaw rated CVSS 8.7 in two LiteLLM endpoints used to preview an MCP server before saving it: POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list. Both accept a full MCP server configuration in the request body, including the command, args, and env fields the stdio transport uses to launch a process. Because LiteLLM runs that configuration to test the connection, any authenticated user can supply a crafted command and run arbitrary commands on the gateway host. The flaw is fixed in LiteLLM 1.83.7, and CISA added it to the Known Exploited Vulnerabilities catalog on June 8, 2026 with a federal remediation deadline of June 22, 2026.

How does the chain with CVE-2026-48710 reach unauthenticated RCE?

On its own, CVE-2026-42271 requires an authenticated user. Horizon3.ai chained it with CVE-2026-48710, a Starlette host-header validation bypass tracked as the BadHost issue, to skip authentication entirely. By sending a request that defeats Starlette's host validation, an attacker reaches the MCP-preview endpoints without valid credentials and triggers the command injection, achieving unauthenticated remote code execution against an exposed LiteLLM deployment. Closing the chain requires both updates: LiteLLM to 1.83.7 or later and Starlette to 1.0.1 or later. Updating only one leaves either the authenticated injection or the auth bypass in place.

What can an attacker do after exploiting CVE-2026-42271?

LiteLLM is an LLM gateway that holds model-provider credentials and proxies traffic to back-end models. Once an attacker runs commands on the gateway host, they can read model-provider credentials, siphon stored API keys and secrets, and move laterally into connected AI infrastructure the gateway can reach. Because the gateway is a central chokepoint, a single compromised host can expose keys for every model and account routed through it. That is why this sits in the CISA KEV catalog with active exploitation cited, and why secret hygiene on the gateway and an inventory of which endpoints reach it both matter alongside the patch.

How does Anomity reduce exposure to this class of flaw?

Anomity inventories every MCP server an endpoint is configured to reach and every gateway and CLI it talks to, as part of the eight AI artifact types it tracks per endpoint, and records metadata such as the LiteLLM client version and the stdio command, args, and env fields used to launch a server. On agents that expose a hook, for example the PreToolUse event in Claude Code, it evaluates each tool call and returns allow, deny, or log before the call runs, so a call routed through an untrusted MCP target is stopped at the boundary. Every decision and configuration change lands in a queryable 90-day audit trail routed to your SIEM. Secrets are redacted on the endpoint, so stored API keys never leave it in the clear.