CRITICAL: LiteLLM RCE Chain Hits CISA KEV as Attackers Hammer Exposed AI Gateways

There is a special kind of irony when the infrastructure built to govern artificial intelligence becomes the easiest path into the rest of your environment. That is exactly what happened to LiteLLM, the open source proxy and Python SDK that thousands of organizations have quietly slotted between their applications and the major model providers. A command injection bug in two preview endpoints, when chained with a host header validation bypass in the Starlette web framework that LiteLLM rides on, hands attackers unauthenticated remote code execution with the privileges of the proxy process. CISA added it to the Known Exploited Vulnerabilities catalog this week, which means the federal government has now formally confirmed what threat researchers had been watching for days. People are getting hit.

The headline vulnerability is CVE-2026-42271, a command injection flaw in LiteLLM versions 1.74.2 through 1.83.6 that carries a standalone CVSS score of 8.7. The mechanics are almost embarrassingly simple. Two endpoints, POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list, exist to let administrators preview a Model Context Protocol server configuration before saving it to the proxy. Reasonable feature on paper. The problem is that those endpoints accept the full MCP server configuration in the request body, including the command, args, and env fields used by stdio transport. Submit a configuration and the proxy obediently spawns whatever command you supplied as a subprocess on the host, running with the proxy process's privileges. The endpoints required only a basic authenticated API key rather than the PROXY_ADMIN role that actually guards the save endpoint, which means any internal user with the lowest tier of access could trivially escalate to command execution on the gateway itself.

That alone would be ugly enough. Anyone who has managed a LiteLLM deployment knows those proxies tend to hold the crown jewels of an AI program, the API keys for OpenAI, Anthropic, Google, and whatever else the engineering team is using, along with the model provider accounts the finance team is footing the bill for. Pop the proxy and you walk away with every credential it touches, plus a foothold for lateral movement into whatever data the AI applications were reading from. Vector databases, internal documentation stores, customer support transcripts, source code repositories. The LiteLLM proxy sees it all flow past on its way to the language model.

The real kick is CVE-2026-48710, the BadHost vulnerability in the Starlette web framework that LiteLLM uses for HTTP routing. Discovered and disclosed by OSTIF, BadHost is a host header validation bypass affecting Starlette versions 1.0.0 and earlier with a standalone CVSS of 6.5. Researchers at Horizon3.ai realized they could chain BadHost with the LiteLLM command injection to completely sidestep the authentication requirement, turning the post auth flaw into a fully unauthenticated remote code execution path. When you combine the two, the effective CVSS score climbs to a perfect 10.0. No credentials needed. No social engineering. Just a crafted HTTP request to an exposed LiteLLM proxy and you are running code as the gateway service account.

CISA's Known Exploited Vulnerabilities catalog now lists CVE-2026-42271 with active exploitation confirmed, which is the kind of formal acknowledgment that usually arrives a beat behind the threat actors. By the time something hits KEV, opportunistic scanning is already widespread and federal agencies have a hard deadline to remediate. The pattern is familiar to anyone who watched LiteLLM's previous critical bug, CVE-2026-42208, a SQL injection in the proxy API key verification logic that scored 9.3 back in April. That one went from disclosure to active exploitation in roughly 36 hours. There is no reason to assume CVE-2026-42271 is moving any slower, especially since the exploit chain is published and the payload is essentially a few lines of HTTP that anyone with curl can produce.

LiteLLM's maintainers, BerriAI, pushed the fix in version 1.83.7, which arrived alongside the GHSA-v4p8-mg3p-g94g advisory credited to researcher jaydns. The Starlette team shipped 1.0.1 to close BadHost on the framework side. If you are running LiteLLM in production, the immediate move is to upgrade the proxy to 1.83.7 or later and bump Starlette to 1.0.1 or later in your dependency tree. Both upgrades should happen together. Patching only one half of the chain still leaves the other half exposed, and the proxy patch alone does not address the underlying Starlette bypass that could affect other components in your stack that also ride on the framework.

If you cannot patch immediately, perhaps because of a change freeze or a dependency conflict that needs negotiation, the workaround is straightforward. Block POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list at the reverse proxy or API gateway in front of LiteLLM. Those endpoints are not required for normal proxy operation, only for administrators previewing MCP server configurations, so blocking them at the edge is a low risk mitigation. While you are in there, take the opportunity to also restrict access to the proxy management interface to internal trusted network segments only, because no AI gateway should ever be answering requests from the open internet anyway. The fact that we have to say that out loud in 2026 is its own story.

For detection, hunt your access logs for any requests to those two MCP test endpoints, since they are not exactly high traffic paths in normal use. Anomalous Host header values are the indicator that ties into the Starlette bypass, so anything that does not match your expected proxy hostnames deserves a closer look. On the host side, instrument for subprocess execution events spawned by the LiteLLM process. The proxy should not be launching arbitrary commands during normal operation, and any unexpected child process is a smoking gun. If you are running Falco, Tetragon, or any decent EDR with Linux process telemetry, you already have the building blocks. Write the rule and stand it up before you sleep tonight.

Credential rotation is the unglamorous but essential cleanup step. Assume any model provider API key that lived in a vulnerable LiteLLM deployment has touched attacker controlled infrastructure. Rotate the keys, audit the usage logs from your providers for anomalous activity, and check whether attackers have been quietly burning your OpenAI tokens to run their own inference workloads on your dime. There has been a steady stream of reports over the past year of compromised LLM gateways being used to bankroll cryptojacking, prompt injection campaigns, and the production of synthetic content at industrial scale. The bill shows up later, and it is not small.

The broader story here is that AI infrastructure has quietly become the same kind of soft target that messaging gateways, VPN appliances, and printer servers used to be a decade ago. LiteLLM is open source, it moves fast, and it sits in a privileged position with credentials for some of the most expensive APIs in the modern stack. That combination is catnip for attackers. The Hacker News reporting confirmed CISA's KEV listing, Horizon3.ai's public writeup makes the exploit chain trivially reproducible for anyone with a working knowledge of Python and HTTP, and Shodan style scanning for exposed LiteLLM instances was already a hobby for the curious before this disclosure. We are going to see more of this. Treat your AI gateways with the same care you give your identity infrastructure, because in practical terms they are part of it now.

For MSPs and security partners watching this unfold, there is a real conversation to be had with clients who have stood up generative AI capabilities over the past year without looping security into the architecture. Most of those deployments happened fast, often driven by an engineering team or a line of business that wanted a quick win. The proxies, the orchestrators, the MCP servers, all of it got deployed before anyone built a threat model around the new attack surface. An AI infrastructure security assessment is a tangible offering you can build around exactly this kind of incident, with credential hygiene reviews, gateway hardening, dependency scanning, and runtime monitoring as the deliverables. Use this CVE as the opening line in your next client conversation. The risk is concrete, the patch path is clear, and the value of having someone watching the new AI plumbing is finally easy to demonstrate.