LiteLLM CVE-2026-42271 Exploited in the Wild — AI Gateway Flaw Chains to Unauthenticated RCE

AI infrastructure is becoming a serious attack surface. The latest example is LiteLLM CVE-2026-42271, a command injection vulnerability in BerriAI LiteLLM that CISA has added to its Known Exploited Vulnerabilities catalog after evidence of active exploitation.

LiteLLM is a popular open-source AI gateway and Python SDK used to route requests to different LLM providers through OpenAI-compatible interfaces. That makes it a sensitive piece of infrastructure. It often sits between applications, users, API keys, model providers, internal tools, and AI workflows.

The vulnerability is dangerous on its own because an authenticated user with a valid proxy API key could execute arbitrary commands on the LiteLLM host. But the risk becomes even more severe when chained with CVE-2026-48710, a Starlette Host header validation bypass. Horizon3.ai reported that this chain can bypass authentication entirely and turn the issue into unauthenticated remote code execution against vulnerable LiteLLM deployments. :contentReference[oaicite:0]{index=0}

What Is CVE-2026-42271?

CVE-2026-42271 is a command injection vulnerability affecting the LiteLLM Python package. According to NVD, LiteLLM versions from 1.74.2 before 1.83.7 are affected. The issue exists in two MCP server preview endpoints that accepted full server configuration data in the request body, including command execution fields used by the stdio transport. :contentReference[oaicite:1]{index=1}

The vulnerable endpoints are:

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

These endpoints were designed to test or preview an MCP server before saving it. The problem was that they accepted fields such as command, args, and env. When called with a stdio configuration, LiteLLM attempted to connect to the supplied server configuration and spawned the provided command as a subprocess on the proxy host.

In simple terms: a user who could access these endpoints could make the LiteLLM proxy run commands on the server.

Why This LiteLLM Vulnerability Matters

This vulnerability matters because LiteLLM is not just another library. It is often deployed as an AI gateway. That means it may hold or access model provider API keys, proxy credentials, environment variables, internal service tokens, logging data, and routing rules for AI traffic.

If attackers gain command execution on the LiteLLM host, they may be able to:

Steal model provider credentials.
Extract API keys and secrets stored by the proxy.
Access environment variables.
Modify AI gateway behavior.
Move laterally into connected AI infrastructure.
Compromise downstream systems integrated with the gateway.
Deploy malware, miners, or persistence mechanisms.

CISA adding CVE-2026-42271 to KEV means defenders should treat it as present danger, not theoretical risk. CISA’s Known Exploited Vulnerabilities catalog is specifically used to highlight vulnerabilities with evidence of exploitation in real attacks. :contentReference[oaicite:2]{index=2}

Affected Versions

The affected LiteLLM versions are:
| Component | Affected Versions | Fixed Version |
|---|---|---|
| LiteLLM | >= 1.74.2 and < 1.83.7 | 1.83.7 or later |
| Starlette | <= 1.0.0 in the reported chain context | 1.0.1 or later |

LiteLLM users should upgrade to 1.83.7 or later. Deployments that include vulnerable Starlette versions should also upgrade Starlette to 1.0.1 or later, especially if LiteLLM or related AI gateway services depend on it. NVD describes CVE-2026-48710 as a Starlette Host header validation flaw fixed in Starlette 1.0.1. :contentReference[oaicite:3]{index=3}

How the Command Injection Works

The core issue is that LiteLLM’s MCP preview endpoints accepted a full server configuration before saving it. That configuration could include fields used by the stdio transport. In a safe design, test endpoints should not allow ordinary authenticated users to cause arbitrary subprocess execution on the proxy host.

The vulnerable flow looked like this:

A user sends a request to one of the MCP test endpoints.
The request body includes a stdio MCP server configuration.
The configuration includes attacker-controlled command, args, or env fields.
LiteLLM attempts to test the connection.
The proxy host spawns the supplied command as a subprocess.

Before the patch, these endpoints were protected by a valid proxy API key. That still created serious risk because any authenticated user, including users with internal keys, could potentially execute commands on the host. The patch in LiteLLM 1.83.7 changed authorization so these test endpoints require the PROXY_ADMIN role, aligning them with the save endpoint behavior described in public reporting. :contentReference[oaicite:4]{index=4}

The Starlette Chain: From Authenticated RCE to Unauthenticated RCE

The most concerning part of this incident is the exploit chain. Horizon3.ai reported that CVE-2026-42271 can be chained with CVE-2026-48710, a Starlette “BadHost” Host header validation bypass, to completely bypass LiteLLM authentication in vulnerable deployments. :contentReference[oaicite:5]{index=5}

Starlette is a lightweight ASGI framework used across many Python web services, including AI infrastructure. CVE-2026-48710 affects Host header validation and can cause differences between the raw requested path and the reconstructed request.url.path. NVD notes that Starlette prior to version 1.0.1 did not validate the HTTP Host header before using it to reconstruct request URLs. :contentReference[oaicite:6]{index=6}

In the LiteLLM chain, this can sidestep the authentication mechanism and expose the vulnerable MCP test endpoints without valid credentials. That changes the risk profile dramatically:

Standalone CVE-2026-42271: authenticated command injection.
Chained with CVE-2026-48710: unauthenticated remote code execution.

Warning: If your LiteLLM deployment includes a vulnerable Starlette dependency and exposes the affected routes, treat this as a critical unauthenticated RCE risk.

Why AI Gateways Are Becoming High-Value Targets

AI gateways are now part of production infrastructure. They manage access to LLM providers, enforce routing logic, store API keys, handle user requests, log prompts and responses, and connect internal applications with external AI services. That makes them attractive to attackers.

A compromised AI gateway can expose more than one application. It may give attackers access to multiple model providers, internal APIs, secrets, and downstream systems. In some environments, the gateway may sit close to sensitive workflows such as customer support automation, document processing, code generation, agent orchestration, or internal knowledge retrieval.

This is why AI gateway vulnerabilities should be handled like vulnerabilities in authentication systems, API gateways, CI/CD systems, or secrets infrastructure. They are not just developer tooling anymore.

How to Check If You Are Vulnerable

Start by checking your LiteLLM version:

pip show litellm

Or check installed packages:

pip freeze | grep -i litellm
pip freeze | grep -i starlette

If you use a requirements file, check for LiteLLM and Starlette:

grep -i "litellm\|starlette" requirements.txt

For Poetry:

poetry show litellm
poetry show starlette

For Docker-based deployments, check the container image, not only the repository:

docker run --rm your-litellm-image pip show litellm
docker run --rm your-litellm-image pip show starlette

You should also check whether these endpoints are reachable from untrusted networks:

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

Do not test exploitation against production. Instead, verify routing, authentication, reverse proxy rules, and logs safely.

How to Fix CVE-2026-42271

The primary fix is to upgrade LiteLLM:

pip install --upgrade "litellm>=1.83.7"

Also upgrade Starlette if it appears in your dependency tree:

pip install --upgrade "starlette>=1.0.1"

Then verify installed versions:

pip show litellm
pip show starlette

If you use pinned dependencies, update your lock file and rebuild your deployment artifact:

pip-compile --upgrade-package litellm --upgrade-package starlette
docker build --no-cache -t your-litellm-image .
docker push your-litellm-image

After upgrading, redeploy and confirm that vulnerable versions are no longer present in production containers, virtual environments, or server images.

Temporary Mitigations If You Cannot Patch Immediately

Patching should be the priority. If immediate patching is not possible, apply temporary controls to reduce exposure:

Block POST /mcp-rest/test/connection at your reverse proxy or API gateway.
Block POST /mcp-rest/test/tools/list at your reverse proxy or API gateway.
Restrict LiteLLM access to trusted network segments only.
Require strong authentication at the edge before traffic reaches LiteLLM.
Rotate credentials stored or used by the LiteLLM proxy.
Review logs for unusual Host header activity.
Review logs for unexpected subprocess execution events.
Audit model provider keys and internal API tokens exposed to the proxy process.

Example Nginx-style blocking rule:

location = /mcp-rest/test/connection {
deny all;
}
location = /mcp-rest/test/tools/list {
deny all;
}

These mitigations reduce immediate risk, but they are not a replacement for upgrading LiteLLM and Starlette.

Detection and Log Review

There is currently limited public detail on exactly how CVE-2026-42271 is being exploited in the wild, including the identity of threat actors, target sectors, and whether observed attacks are using the full Starlette chain. Public reporting notes that CISA added the flaw to KEV, but exploitation details remain limited. :contentReference[oaicite:7]{index=7}

Security teams should review:

Requests to /mcp-rest/test/connection.
Requests to /mcp-rest/test/tools/list.
Requests with unusual or malformed Host headers.
LiteLLM proxy logs around MCP test activity.
Unexpected subprocess execution by the LiteLLM process.
Outbound network connections from the LiteLLM host.
Access to environment variables, secrets, or credential files.
New files, cron jobs, shell scripts, or unknown processes on the host.

If you find suspicious activity, rotate model provider API keys and other secrets accessible to LiteLLM. Treat the host as potentially compromised until reviewed.

Related LiteLLM Security Context

This is not the first major LiteLLM vulnerability in 2026. Public reporting notes that CVE-2026-42208, a critical SQL injection flaw in LiteLLM, came under active exploitation within 36 hours of public disclosure. That earlier issue affected LiteLLM proxy server API key validation and could allow database access or modification in vulnerable versions. :contentReference[oaicite:8]{index=8}

Together, these incidents show that AI gateway infrastructure is now being watched closely by both defenders and attackers. Teams deploying AI infrastructure should expect the same level of scrutiny and exploitation speed seen in web frameworks, VPNs, CI/CD platforms, and identity systems.

How Vulert Helps Detect Vulnerable LiteLLM Dependencies

Vulert is a Software Composition Analysis tool that monitors open-source dependencies for security vulnerabilities. It analyzes manifest files and SBOMs to detect known vulnerabilities across direct and transitive dependencies without requiring access to source code.

For Python projects using LiteLLM, Vulert can help identify vulnerable dependency versions through files such as requirements.txt, Pipfile.lock, and SBOMs. It also supports other ecosystems and files including package-lock.json, yarn.lock, pnpm-lock.yaml, composer.lock, Gemfile.lock, go.mod, pom.xml, gradle.lockfile, sbom.json`,bom.json,spdx.json`, and CycloneDX/SPDX SBOMs.

Vulert cross-references dependency versions against 458,000+ CVEs and alerts teams when newly disclosed vulnerabilities affect their packages. It also provides fix guidance, exact safe versions, and CLI commands where available. This helps teams move faster when vulnerabilities like LiteLLM CVE-2026-42271 become actively exploited.

Key Takeaways

CVE-2026-42271 is actively exploited: CISA added the LiteLLM command injection flaw to the Known Exploited Vulnerabilities catalog.
Affected LiteLLM versions: Versions from 1.74.2 before 1.83.7 are vulnerable.
The impact is command execution: Vulnerable MCP test endpoints can spawn attacker-supplied commands as subprocesses on the proxy host.
The Starlette chain is worse: CVE-2026-48710 can bypass authentication and make the issue unauthenticated RCE in affected deployments.
Patch immediately: Upgrade LiteLLM to 1.83.7+ and Starlette to 1.0.1+.
Rotate secrets if exposed: LiteLLM may have access to model provider credentials, API keys, and internal service tokens.

Frequently Asked Questions

1. What is CVE-2026-42271?

CVE-2026-42271 is a command injection vulnerability in BerriAI LiteLLM. It affects MCP server test endpoints that accepted server configuration fields capable of causing subprocess execution on the LiteLLM proxy host.

2. What should I do if I cannot patch immediately?

Block the affected MCP test endpoints at the reverse proxy, restrict access to trusted networks, rotate credentials, review logs for suspicious Host header and subprocess activity, and patch as soon as possible.

3. Can Vulert detect vulnerable LiteLLM versions?

Yes. Vulert can scan Python dependency files and SBOMs to identify vulnerable LiteLLM versions and provide fix guidance when available.

推荐订阅源

DEV Community