LiteLLM CVE-2026-42271: The AI Gateway Flaw That Turns a Low-Privilege Key Into Remote Code Execution

An attacker who can reach your LiteLLM server can run shell commands on the machine that holds every AI API key your team uses. That is the practical effect of CVE-2026-42271, a command injection flaw that CISA added to its Known Exploited Vulnerabilities catalog on June 8, with a federal patch deadline of June 22. The catalog entry exists because the bug is already being used in real attacks, not because someone filed a theoretical report.

LiteLLM is the open-source proxy a lot of small teams reach for when they want one endpoint, one set of credentials, and one bill in front of OpenAI, Anthropic, Azure, and a dozen other model providers. It is convenient, it is popular, and in plenty of the small businesses we look at it is sitting on a box that nobody has touched since the afternoon it was set up.

Whether this one is yours

Here is the honest read for an owner who does not want to chase every CVE. If your developers call model providers directly from application code and you have never heard the phrase "AI gateway," you can close this tab; this one is not aimed at you. If anyone on your team stood up a shared proxy so the company could centralize its AI spend and keys - and that is precisely what LiteLLM is built for - then you are in scope, the fix is small, and the window to apply it is this week.

What makes ten minutes of attention worth it is what sits behind the gateway. The proxy stores the API keys for every model provider it talks to. Whoever runs commands on that host can read those keys, run up charges on your accounts, and reach into whatever else the box can see on your network. Horizon3.ai, the firm that proved out the attack, described the payoff in plain terms: execute arbitrary commands on the host, access model-provider credentials, and steal API keys. For a small company, the most expensive part is rarely the cleanup of one server; it is the surprise five-figure bill from a provider account an attacker drained over a weekend.

What CVE-2026-42271 actually is

LiteLLM ships a pair of test endpoints used to check connections to Model Context Protocol (MCP) servers. According to the vendor's security advisory GHSA-v4p8-mg3p-g94g, the two endpoints are POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list. Both accept a full server configuration in the request body, including the command, args, and env fields that LiteLLM uses for the stdio transport. When the proxy processes that configuration, it spawns the supplied command as a subprocess on the host, running with the privileges of the LiteLLM process itself.

The flaw that turns a feature into a foothold is the access check. The advisory states the endpoints were "gated only by a valid proxy API key, with no role check." Any authenticated user, including the holder of a low-privilege internal-user key handed out so a teammate could test a model, could send a request that runs a command of their choosing. It is tracked as CWE-78 (OS command injection) with a base CVSS of 8.7, and it affects LiteLLM from version 1.74.2 up to 1.83.7, where the fix landed. The patched build enforces the PROXY_ADMIN role on both endpoints, which is the behavior they should have had from the start. Full enrichment is on the NVD record.

In a log, the malicious traffic looks like an ordinary test call with a hostile payload. The shape a defender should recognize is a POST to one of those two paths carrying a stdio server block:

POST /mcp-rest/test/connection HTTP/1.1
Host: your-litellm-host
x-litellm-api-key: sk-...           # any valid key, no admin role needed
Content-Type: application/json

{
  "transport": "stdio",
  "command": "/bin/sh",
  "args": ["-c", "id; cat /proc/1/environ"],
  "env": {}
}

How a low-privilege bug became unauthenticated

On its own, CVE-2026-42271 still requires some valid key. The reason it now carries a federal deadline is that researchers removed the key requirement entirely. Horizon3.ai chained it with the LiteLLM advisory path to a second bug, CVE-2026-48710, the Starlette "BadHost" host-header validation bypass that the Open Source Technology Improvement Fund disclosed in May. Starlette is the web framework underneath LiteLLM's API. When a deployment's dependency tree includes Starlette 1.0.0 or earlier, an attacker can forge the Host header to defeat the checks that were supposed to keep the request out, and the authentication requirement on the command-injection endpoints disappears. The result is unauthenticated remote code execution, rated CVSS 10.0 as a chain.

We covered the BadHost bug when it first surfaced, because it quietly breaks the auth assumptions of a large number of FastAPI and Starlette applications, not just this one. The LiteLLM chain is the clearest example so far of why a host-header bug that sounds abstract is worth patching. The timeline is short enough to take seriously: the command-injection issue was disclosed on April 20, LiteLLM published the fix in version 1.83.7 on May 8, the Starlette bypass became public on May 26, Horizon3.ai validated the full unauthenticated chain on June 1, and CISA listed it as actively exploited on June 8. Six weeks from disclosure to a federal patch order is not a generous runway.

Find your gateway and check the version

The practitioner work starts with inventory, because the AI gateway is almost never on the asset list when we run discovery on a small dev team. It gets stood up fast, often in a container on a developer's project, and then it is forgotten while it keeps routing traffic. Two checks tell you where you stand: the LiteLLM version and the Starlette version in the same environment.

# If LiteLLM runs as a Python package:
pip show litellm 2>/dev/null | grep -i version
pip show starlette 2>/dev/null | grep -i version

# If it runs as a container, read the running image and its installed deps:
docker ps --format '{{.Image}}' | grep -i litellm
docker exec <container> pip show litellm starlette | grep -iE 'name|version'

# Then hunt your reverse-proxy access log for probes of the two endpoints
# and for the forged-Host requests that signal the auth bypass:
grep -E '/mcp-rest/test/(connection|tools/list)' /var/log/nginx/access.log
awk '$0 !~ /Host: (your-litellm-host|localhost)/ {print}' /var/log/nginx/access.log | head

If litellm reports anything from 1.74.2 up to but not including 1.83.7, you are running a vulnerable build. If starlette reports 1.0.0 or lower, assume the unauthenticated chain applies and treat any hit on those endpoint paths as an attempted compromise until you can prove otherwise. A clean log across the relevant dates is the answer you want, and most teams will get it.

Patch, rotate, and block, in that order

The order matters because patching alone does not undo a theft that already happened. Work through these three steps the same week you find an affected gateway.

1. Upgrade both packages

Move LiteLLM to 1.83.7 or later and Starlette to 1.0.1 or later. Upgrading LiteLLM closes the command injection by enforcing the admin role; upgrading Starlette closes the host-header bypass that made it reachable without a key. Patch both, since each one removes a different link in the chain.

2. Rotate every credential the proxy held

Assume any key stored on a vulnerable gateway has been read. Rotate the model-provider API keys (OpenAI, Anthropic, Azure, and the rest), the LiteLLM master key, and any database or cloud credentials configured on that host. Watch the provider billing dashboards for unexpected usage spikes over the days the gateway was exposed.

3. Block the endpoints if you cannot patch today

If an upgrade has to wait for a change window, deny the two test paths at your reverse proxy and keep the gateway off the public internet. The vendor advisory recommends exactly this. A minimal nginx block looks like:

location ~ ^/mcp-rest/test/(connection|tools/list) {
    deny all;
    return 403;
}

# And bind the gateway to an internal segment, not 0.0.0.0:
# listen 10.0.0.0:4000;   # reachable from app servers only, never the edge

AI infrastructure is ordinary infrastructure

This is the second serious LiteLLM bug we have written up in recent months; earlier this year a pre-authentication SQL injection in the same product could expose the cloud account behind it. The repeating pattern is not really about one project's code quality. It is about how the gateway gets treated. A small team adopts an AI proxy as a developer convenience, points it at the company's most valuable API keys, exposes it so a couple of services can reach it, and then never files it under "internet-facing applications that need patching and monitoring." Attackers have noticed that this category of box is widely deployed, holds credentials, and is rarely watched.

The correction is unglamorous and cheap. Put every AI gateway, MCP server, and agent host on the same asset inventory as your web servers. Give it the same patch clock, the same network restrictions, and the same log collection. The moment a piece of AI plumbing holds real secrets and answers real requests, it earns the same scrutiny as any other server that does.

Rotate the keys and close the test endpoints today

If you run LiteLLM, the next move is concrete: upgrade to 1.83.7 and Starlette to 1.0.1, rotate every key the proxy stored, and block the two MCP test endpoints at the edge until both upgrades are confirmed. CISA's June 22 deadline is written for federal agencies, but the exploitation it reflects does not check whether you are one. We help small teams review the LLM gateways, MCP servers, and agent deployments that quietly accumulate in their environments, find the ones that are exposed, and right-size the controls around them. If you cannot name the AI infrastructure you are running or say who can reach it, that is the conversation to have before an attacker maps it for you.