Hackers are exploiting LiteLLM RCE flaw used to run commands on AI gateway servers

Hackers are actively exploiting a LiteLLM command injection vulnerability that can let attackers run operating system commands on affected AI gateway servers. The flaw is tracked as CVE-2026-42271, and CISA has now added it to its Known Exploited Vulnerabilities catalog after evidence of attacks in the wild.

The issue affects LiteLLM deployments running versions 1.74.2 through versions before 1.83.7. According to the NVD entry for CVE-2026-42271, two MCP test endpoints accepted full server configurations, including command, args, and environment fields used by the stdio transport.

When those endpoints received a stdio configuration, LiteLLM could spawn the supplied command as a subprocess on the proxy host. That means successful exploitation can give attackers command execution with the privileges of the LiteLLM proxy process.

LiteLLM RCE bug is now linked to active attacks

LiteLLM is widely used as an AI gateway for routing requests to model providers and internal AI services. That role makes the proxy layer valuable because it can hold API keys, provider credentials, internal network access, and other secrets.

The original LiteLLM security advisory describes CVE-2026-42271 as an authenticated command execution issue. The affected endpoints were gated by a valid proxy API key, but they lacked a role check, which meant even low-privilege internal-user keys could reach the vulnerable path.

The risk increased after Horizon3.ai showed that attackers could chain the LiteLLM flaw with the Starlette BadHost vulnerability, tracked as CVE-2026-48710. In its LiteLLM unauthenticated RCE analysis, Horizon3.ai said the chain can bypass the API key requirement in vulnerable deployments and allow command execution without credentials.

Issue	Product	Impact	Fix
CVE-2026-42271	LiteLLM	Command execution through MCP stdio test endpoints	Upgrade to LiteLLM 1.83.7 or later
CVE-2026-48710	Starlette	Host header validation bypass that can weaken path-based security checks	Upgrade to Starlette 1.0.1 or later
Chained attack path	LiteLLM with vulnerable Starlette dependency	Unauthenticated remote code execution in affected deployments	Patch both LiteLLM and Starlette, then rotate exposed secrets

How the LiteLLM attack chain works

The vulnerable LiteLLM endpoints are POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list. These endpoints let users preview an MCP server before saving it, but the vulnerable implementation accepted fields that could define a command to run.

The GitHub advisory says LiteLLM fixed the flaw in version 1.83.7 by requiring the PROXY_ADMIN role for both test endpoints. If admins cannot upgrade immediately, the advisory recommends blocking both endpoints at a reverse proxy or API gateway.

The second bug sits in Starlette, a Python ASGI framework used across many web and AI-related services. The Starlette advisory says affected versions did not validate the HTTP Host header before reconstructing request.url, which could make request.url.path differ from the real requested path.

• LiteLLM versions from 1.74.2 up to, but not including, 1.83.7 are affected by CVE-2026-42271.
• Starlette versions before 1.0.1 are affected by CVE-2026-48710.
• The LiteLLM flaw allows command execution when a vulnerable MCP stdio test endpoint gets malicious configuration data.
• The Starlette flaw can bypass security checks that rely on reconstructed request URLs.
• The combined chain can remove the LiteLLM API key barrier in vulnerable deployments.

Why AI gateway compromise is serious

A compromised LiteLLM proxy can expose more than one application. Many organizations use an AI gateway to centralize access to OpenAI-compatible APIs, internal model services, cloud-hosted inference systems, and third-party providers.

Attackers who gain command execution on that layer may be able to read environment variables, steal model provider API keys, access cloud credentials, inspect internal service routes, and pivot into connected infrastructure. The Horizon3.ai report specifically warns that exploitation can allow attackers to run commands as the LiteLLM proxy process and access secrets stored by the proxy.

CISA’s listing adds urgency because the agency reserves the KEV catalog for vulnerabilities with evidence of real-world exploitation. Organizations running self-hosted LiteLLM instances should treat exposed deployments as a priority.

Indicators and mitigation steps

Admins should first confirm whether LiteLLM and Starlette appear anywhere in their production, staging, or internal AI infrastructure. Container images, virtual environments, and dependency lock files should all be checked because vulnerable dependency chains may remain even after partial updates.

The National Vulnerability Database confirms that CVE-2026-42271 affects LiteLLM from 1.74.2 to before 1.83.7 and was patched in version 1.83.7. For Starlette, the GitHub security advisory lists affected versions before 1.0.1 and recommends upgrading to 1.0.1.

Security teams should also review logs for requests to the MCP test endpoints, unusual Host header values, unexpected subprocess execution from the LiteLLM process, and unauthorized command execution events on the host.

What to check	Why it matters
Requests to /mcp-rest/test/connection	This endpoint is one of the affected MCP test paths.
Requests to /mcp-rest/test/tools/list	This endpoint can also trigger the vulnerable stdio preview behavior.
Malformed or unusual Host headers	These may indicate attempts to exploit the Starlette BadHost bypass.
Unexpected subprocesses from LiteLLM	This can indicate successful command execution.
Access to environment variables or secret files	Attackers may try to steal API keys and provider credentials after exploitation.

Patch and rotate secrets immediately

Organizations should upgrade LiteLLM to 1.83.7 or later and Starlette to 1.0.1 or later. After patching, teams should rebuild containers, redeploy affected services, and verify that old vulnerable packages do not remain in active runtime environments.

If patching cannot happen immediately, admins should block access to the affected MCP test endpoints at the reverse proxy or API gateway, restrict LiteLLM access to trusted networks only, and disable public exposure where possible.

Because successful exploitation can expose secrets, patching alone may not be enough. Teams should rotate LiteLLM proxy keys, model provider API keys, cloud credentials, and any secrets stored in environment variables or configuration files on the affected host.

FAQ