Reported by 5 outlets
BadHost (CVE-2026-48710) — Starlette Host Header Injection Bypasses Authentication, Affecting FastAPI, vLLM, and MCP AI Servers
Why this score
- Breadth
- 2.00 / 2.0 · 5 sources
- Authority
- 1.00 / 2.0 · best outlet weight
- Severity
- 5.00 / 5.0 · CVSS + KEV signals
- Velocity
- 0.00 / 2.0 · updates in 48h
- Pickup speed
- 0.08 / 0.6 · time to second source
- Recency
- × 0.00 temporal multiplier
- Community
- + 0.00 / 1.5 · reddit signal
- Score
- 0.0 / 10 = base × recency + community
Desk analysis
Starlette reconstructs request URLs by splicing the unvalidated Host header into the URL, so a Host value carrying a path-altering character such as /, ? or # makes request.url.path diverge from the path the router actually dispatched, and any middleware that enforces authentication on request.url.path can be walked around. CVE-2026-48710, found by X41 D-Sec researchers credited on the advisory, covers Starlette from 0.8.3 through 1.0.0 in a framework pulling roughly 325 million weekly downloads, fixed in 1.0.1 on May 21, 2026. Chained with CVE-2026-42271 it stops being a bypass and becomes unauthenticated remote code execution: LiteLLM 1.74.2 through 1.83.6 expose MCP server test endpoints, POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list, that spawn the command, args and env supplied in the request body as a subprocess on the proxy host, and the crafted Host header strips the proxy API key requirement that had contained the flaw to authenticated users. Horizon3.ai validated the full chain end to end, and CVE-2026-42271 sits in CISA's KEV catalog with EPSS at 12.754 percent.
The LiteLLM proxy is the choke point between an organization and its model providers, so code execution there means theft of every provider API key and stored secret, control of all AI API traffic passing through the gateway, and a pivot into connected inference infrastructure. Exploitation needs only network reachability plus one malformed header, no credentials and no user interaction, and the same Host bug generalizes to vLLM servers, MCP implementations, and any FastAPI app doing path-based middleware checks. What the event stream does not spell out is the disclosure lag: the LiteLLM fix shipped April 19, the vendor advisory followed April 21 rated 8.7 High on the assumption of an authenticated low-privilege attacker, the Starlette fix landed May 21 as a one-line changelog entry naming no CVE, the CVE id was assigned May 26, and the GitHub advisory for the Starlette bug did not publish until June 4, a week after first coverage. For most of that window a defender watching CVE feeds saw no signal at all while a KEV-listed flaw sat one header away from a 10.0 chained path; the headline severity is a property of running both packages together, which only a dependency audit of the actual host will reveal.
Upgrade Starlette to 1.0.1 or later and LiteLLM to 1.83.7 or later, then rotate every credential the proxy stores, since unpatched deployments running since April are the population Horizon3's confirmation puts at risk. Where an upgrade must wait, block POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list at the reverse proxy or API gateway, the workaround the LiteLLM advisory itself prescribes, and reject Host headers containing /, ? or # at the edge. In Starlette or FastAPI middleware, read request.scope["path"] instead of request.url.path. Hunt in proxy and gateway access logs for requests to either test endpoint carrying anomalous Host values, and in endpoint telemetry for child processes spawned by the LiteLLM proxy process, because the stdio transport executes attacker-supplied commands directly rather than through a shell artifact you would otherwise see.
Two developments would change this assessment. If CVE-2026-48710 lands in KEV or receives severity enrichment above the Moderate rating its GitHub advisory currently carries, exposure widens from LiteLLM estates to the entire FastAPI, vLLM and MCP server base. Public weaponization of the Horizon3 chain, whether PoC code or a scanning spike against /mcp-rest paths, would move LiteLLM operators from patch-now to incident-hunt. One more data point for inventory work: Starlette's release notes show Host header handling hardened again as late as 1.7.0 in September for routing and redirect middleware, so pinned, forked or vendored builds need checking beyond the 1.0.1 bump.
Timeline
-
original reporting
BadHost (CVE-2026-48710) — Starlette Host Header Injection Bypasses Authentication, Affecting FastAPI, vLLM, and MCP AI Servers
cyberpress.org · 139d ago · May 28th, 2026
A critical vulnerability in Starlette (the Python ASGI framework powering FastAPI, vLLM, LiteLLM, and countless AI agent frameworks) allows complete authentication bypass using a single malformed HTTP Host header. Tracked as CVE-2026-48710 and discovered by X41 D-Sec during an OSTIF-sponsored audit, the flaw affects all Starlette versions from 0.8.3 to 1.0.1 — a framework with ~325 million weekly downloads.
Starlette reconstructs URLs using
{scheme}://{host_header}{path}without validating the Host header against RFC 9112 §3.2. An attacker injecting path-altering characters (/,?,#) into the Host header causes Starlette's routing engine and middleware to see different paths — enabling authentication bypass, SSRF, and in confirmed cases, remote code execution. Impacted ecosystems include vLLM and LiteLLM inference servers, MCP (Model Context Protocol) servers for AI agent orchestration, and any FastAPI application using path-based middleware. Fixed in Starlette 1.0.1 (May 21, 2026). Mitigations: upgrade Starlette, replacerequest.url.pathwithrequest.scope["path"]in middleware, deploy nginx to reject malformed Host headers. -
update from github.com
LiteLLM v1.83.7-stable release
github.com · 178d ago · April 19th, 2026
The LiteLLM fix release for CVE-2026-42271 shipped on April 19, 2026, including the pull request titled "fix(mcp): block arbitrary command execution via stdio transport" (PR #25343) and the version bump from 1.83.6 to 1.83.7. The release page shows the tag released April 19 with the underlying commit signature verified April 18, 2026, 10:31 PM UTC. The changelog entry does not name the CVE or the affected endpoints.
-
update from github.com
GHSA-v4p8-mg3p-g94g: LiteLLM: Authenticated command execution via MCP stdio test endpoints
github.com · 176d ago · April 21st, 2026
The vendor advisory for CVE-2026-42271 was published April 21, 2026 in the BerriAI/litellm repository and reviewed into the GitHub Advisory Database on April 25. It describes two MCP preview endpoints, POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list, that spawned an attacker-supplied command as a subprocess on the proxy host and were gated only by a valid proxy API key with no role check; affected versions are 1.74.2 through before 1.83.7, fixed in 1.83.7 by requiring the PROXY_ADMIN role. The advisory rates the flaw High at CVSS v4 8.7, lists blocking both endpoints at a reverse proxy as the workaround, and references the CISA Known Exploited Vulnerabilities catalog entry for the CVE.
-
update from nvd.nist.gov
NVD record for CVE-2026-42271
nvd.nist.gov · 159d ago · May 8th, 2026
By the time the record appeared, the fix had been available for roughly three weeks. This is the registry milestone between the vendor advisory and the news coverage the story was built from.
-
update from github.com
Starlette Version 1.0.1 release note
github.com · 145d ago · May 21st, 2026
This is the vendor fix announcement predating the story's first coverage by a week.
-
update from pypi.org
starlette 1.0.1 on PyPI
pypi.org · 145d ago · May 21st, 2026
PyPI's JSON API records the starlette 1.0.1 distribution upload at 2026-05-21T21:58:56 UTC, minutes after the GitHub release. The patched wheel was therefore publicly installable from May 21, 2026, seven days before the story's first_seen of May 28.
-
update from cybersecuritynews.com
LiteLLM RCE Chain Actively Exploited — CVE-2026-42271 + CVE-2026-48710, CVSS 10.0, Unauthenticated RCE on AI Gateway Proxy
cybersecuritynews.com · 127d ago · June 9th, 2026
Threat actors are actively exploiting a chained vulnerability in LiteLLM, the popular open-source AI gateway proxy, combining two flaws for a CVSS 10.0 unauthenticated remote code execution attack path requiring zero credentials. Horizon3.ai researchers confirmed the chain works end-to-end. How it works: CVE-2026-42271 is a command injection flaw in LiteLLM's Model Context Protocol (MCP) server test endpoints — endpoints like
POST /mcp-rest/test/connectionandPOST /mcp-rest/test/tools/listaccept full server configurations (commands, args, environment variables) and spawn the supplied input as a subprocess on the host. When initially disclosed on April 20, the flaw was considered limited because exploitation required a valid proxy API key. By manipulating the HTTP Host header, attackers sidestep LiteLLM's API key requirement entirely. Impact: Once code execution is achieved, attackers can execute arbitrary OS commands on the LiteLLM host, steal API keys and model provider credentials stored by the proxy, access secrets and environment variables, and move laterally into connected AI infrastructure and downstream systems. The LiteLLM proxy sits at the gateway layer between organizations and LLM providers — compromising it means the attacker controls the choke point for all AI API traffic. Action: Upgrade LiteLLM to 1.83.7+ and Starlette to 1.0.1+ as emergency priority. Monitor for requests targeting/mcp-rest/test/connectionor/mcp-rest/test/tools/listwith anomalous Host header values.