LiteLLM CVE-2026-42271: MCP test endpoints plus BadHost add up to unauthenticated RCE (CVSS 10.0) — picked up retroactively
Picked up on request, deliberately not a 48h item: CVE-2026-42271 was disclosed back on 9 June 2026 and added to CISA's KEV catalog on 8 June — but its full impact only becomes visible in combination with CVE-2026-48710 (BadHost, the Starlette host-header bypass), already covered on this blog. On its own, CVE-2026-42271 is a command injection in two LiteLLM MCP test endpoints (CVSS 8.7) that accept a full server configuration body including command, arguments, and environment variables — authenticated users can execute arbitrary commands through it. Chained with BadHost, which can itself defeat authentication, the combined CVSS rating is 10.0: unauthenticated remote code execution. CISA confirms active exploitation. Fix: LiteLLM ≥1.83.7 with Starlette ≥1.0.1 — both links in the chain need closing.
TL;DR — 90 seconds
Affected?
LiteLLM ≥1.74.2 and <1.83.7, especially combined with Starlette before 1.0.1 (BadHost, CVE-2026-48710). The two endpoints POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list are the attack path.
Risk?
Command injection (CVSS 8.7 alone) → chained with BadHost into unauthenticated RCE (CVSS 10.0 combined). Actively exploited per the CISA KEV listing.
Immediate action?
Update LiteLLM to ≥1.83.7 AND Starlette to ≥1.0.1 — patching only one of the two components doesn't fully close the chain.
Recommendation?
Anyone who patched the already-covered BadHost finding (CVE-2026-48710) but didn't separately update LiteLLM remains exploitable via the MCP test endpoints — both advisories need checking together.
LiteLLM is a widely used AI gateway/proxy that provides unified access to various LLM providers and also supports the Model Context Protocol (MCP). Two preview endpoints, POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list, accept a full server configuration in the request body — including command, args, and env fields. These fields are insufficiently validated, allowing authenticated users to execute arbitrary commands on the host.
On its own, this requires authenticated access. The real severity comes from chaining with CVE-2026-48710 (BadHost): Starlette before version 1.0.1 incorrectly reconstructs request.url from the Host header, which under certain conditions can defeat authentication itself. Combined, this creates a path to fully unauthenticated remote code execution — hence the combined CVSS rating of 10.0.
Who is affected?
Component
Affected version
Safe version
LiteLLM
≥1.74.2, <1.83.7
≥1.83.7
Starlette (dependency)
before 1.0.1
≥1.0.1
Both components need updating to fully close the chain: LiteLLM alone only closes the command-injection endpoints, Starlette alone only closes the host-header bypass. Anyone who already patched the separately-covered BadHost finding (the Starlette side) but hasn't pulled LiteLLM to ≥1.83.7 remains vulnerable to authenticated attackers via the MCP test endpoints.
Impact
The combined path — unauthenticated remote code execution on an AI gateway — is maximally critical: LiteLLM instances typically bundle API keys for multiple LLM providers, routing configuration, and often access to downstream internal systems. A successful attack means full compromise of the gateway host, access to all managed provider keys, and potentially a pivot point into the internal network. Even without the BadHost chain, the command injection remains a serious risk for authenticated users in environments with multiple users of differing trust levels.
Mitigation / immediate steps
Note: based on the cited reporting and the CISA KEV listing — reconcile concrete version levels against the official LiteLLM and Starlette release notes.
Operational decision block
Act now if … you run LiteLLM in a version between 1.74.2 and <1.83.7 — regardless of Starlette patch status.
Check with priority if … you've already addressed the BadHost finding but aren't sure whether LiteLLM was updated separately.
Monitor only if … you're already on LiteLLM ≥1.83.7 with Starlette ≥1.0.1.
Step 1 — update both components
# check LiteLLM version
pip show litellm | grep Version
# update to the safe version
pip install --upgrade litellm>=1.83.7
# check and update Starlette separately
pip show starlette | grep Version
pip install --upgrade starlette>=1.0.1
Step 2 — block the MCP test endpoints at the reverse proxy (until patched)
# example nginx: block the two preview endpoints
location ~ ^/mcp-rest/test/(connection|tools/list) {
deny all;
}
Step 3 — restrict network access
# don't expose the LiteLLM gateway directly to the public
# restrict access to known, trusted source IPs (firewall/security group)
Step 4 — rotate proxy credentials
# after suspected compromise:
# rotate all provider API keys managed through LiteLLM
# regenerate LiteLLM's own master/proxy keys
Detection / verification
Check version
pip show litellm starlette | grep -E "Name|Version"
- unexpected subprocess execution originating from the LiteLLM process
- outbound connections from the LiteLLM instance to unfamiliar destinations
- requests to the MCP test endpoints from sources outside known users/systems
Operator guidance
Mid-market
Update both components (LiteLLM and Starlette) in one step — a partial patch doesn't close the chain. If you've already implemented the BadHost post's guidance, specifically check LiteLLM separately now.
Enterprise
Run a dependency scan across all services using Starlette or LiteLLM — both are frequently transitive dependencies in larger Python/ASGI stacks and easy to overlook. Network-segment AI gateways like LiteLLM: no direct public access, but behind an auth proxy and allowlist.
AI platform operations
LiteLLM as a central gateway bundles provider keys for the entire stack — a compromise here has disproportionate impact. Rotate master/proxy keys regularly as a general hygiene measure, independent of current patch status.
Decision block
Act today if: LiteLLM <1.83.7 regardless of Starlette status. Monitor if: both components already on a safe version.
Frequently asked questions about CVE-2026-42271
Is this the same as the already-covered BadHost finding?+
No, but closely related: BadHost (CVE-2026-48710) is the Starlette-side auth bypass; CVE-2026-42271 is the LiteLLM-side command injection. Only together do they form the unauthenticated RCE chain with a combined CVSS of 10.0.
Why is a June finding being picked up retroactively now?+
Because the combined impact (unauthenticated RCE via chaining) goes beyond the already-covered standalone BadHost finding and needs its own concrete guidance for LiteLLM operators — not because it's a 48h finding.
Is it enough to just update LiteLLM?+
No — that only closes the command-injection endpoints. Without Starlette ≥1.0.1, the host-header bypass remains open, through which authentication itself can be circumvented.
Does this affect me if I only use LiteLLM internally?+
That reduces the risk (no remote access from outside) but doesn't close it: the command injection only requires an authenticated user, and internal threats (compromised internal accounts) remain relevant.
Is there any indication of how active exploitation is actually happening?+
Per the cited sources, no detailed information on the exact exploitation pattern is available at this time — CISA merely confirms active exploitation without further detail.
Conclusion
CVE-2026-42271 is a textbook example of why single-CVE analysis can fall short: on its own, a command injection requiring authentication; combined with an already-known framework bug, fully unauthenticated RCE. Anyone who already implemented the BadHost post's guidance should now specifically check whether LiteLLM itself is on the safe version — the chain is only closed when both links are patched.
I close the full LiteLLM/Starlette RCE chain — version audit, endpoint hardening, and key rotation included.
Version audit of LiteLLM and Starlette across all services, hardening of the MCP test endpoints at the reverse proxy, network segmentation for AI gateways, and rotation of all provider keys managed through LiteLLM.
Platform operations instead of advice on paper: I continuously check, patch and harden your AI gateway infrastructure — including vulnerabilities chained across multiple advisories.
Programming since 2002 – self-taught, set up my own business with KO-Web in 2012. Over 100 projects, with a focus on security, performance, automation and quality. Today freelance: DevSecOps consulting, training and software development.
![[Translate to English:] Foto von Kai Ole Hartwig.](/fileadmin/_processed_/e/9/csm_ole-neu_73323ad80d.jpeg)