Starlette BadHost Host-Header Auth Bypass Hits AI Gateways - CVE-2026-48710

On May 21, 2026, the Starlette project shipped version 1.0.1 to fix CVE-2026-48710, nicknamed BadHost, a host-header authentication bypass affecting all Starlette releases before 1.0.1. Because Starlette is the ASGI toolkit beneath FastAPI and is reported at over 325 million downloads per week, the flaw reaches a vast set of Python AI tools, including vLLM, LiteLLM, and many MCP servers. This advisory covers what the bug does, why a shared-dependency bypass is an agentic-endpoint problem, and how Anomity surfaces and governs the AI services that inherit it.

What happened

Starlette reconstructs request.url by concatenating the incoming HTTP Host header with the request path and then re-parsing the combined string. In the affected versions it does this without first validating the Host value against the RFC 9112 and RFC 3986 grammar that defines a legal host.

That ordering is the flaw. When an attacker injects a character such as /, ?, or # into the Host header, the re-parse places the path boundary in the wrong spot. The result is that request.url.path diverges from the path the ASGI server actually routed against. Middleware that makes a security decision on request.url.path, such as a path-prefix authorization check, sees a path that differs from the one the application will serve. The check can be satisfied while the underlying route still executes, so a request that should have been rejected is allowed through.

Because the same trick lets an attacker steer how Starlette interprets a request target, it can also be turned toward server-side request forgery. BadHost did not stay theoretical: it was the authentication-bypass half of the LiteLLM unauthenticated remote code execution chain tracked as CVE-2026-42271, where the host-header bypass let a request reach a downstream stage it should never have been allowed to touch.

The fix in Starlette 1.0.1 restores correct parsing and validates the Host value before it is used to rebuild the URL, so request.url.path once again matches the routed path.

Why this is an agentic-endpoint risk

Starlette rarely appears by name in an AI deployment. It arrives as a transitive dependency of FastAPI, which is in turn the web layer for vLLM's OpenAI-compatible server, LiteLLM Proxy, and a large number of MCP servers. A team can run an affected build without ever writing import starlette. On a managed endpoint, each of those services is an AI artifact in its own right, and so are the Claude Code sessions, CLIs, and other MCP servers that point at them.

The bypass matters because these services are exactly the places where path-based authorization is common. An LLM gateway gates /admin and key-management routes by prefix; an MCP server gates a tool-invocation path. BadHost lets a crafted Host header make that prefix check read the wrong path while the protected route still runs. Network and EDR controls see the connection but cannot tell you which AI services on which endpoints carry a vulnerable Starlette, or which agents were configured to route through them.

This is the same artifact-layer blind spot we track across the gateway cluster, including the sibling case in LiteLLM pre-auth SQL injection - CVE-2026-42208 and the chain that builds on BadHost in LiteLLM MCP preview remote code execution - CVE-2026-42271. The gateway is one node in a graph of AI artifacts, and you can't govern what you can't see. Fleet-wide inventory of every AI artifact is the precondition for scoping an incident like this one.

How Anomity surfaces and governs it

Anomity inventories eight AI artifact types on every managed endpoint: AI agents, MCP servers, extensions, skills, plugins, secrets, hooks, and CLIs. For CVE-2026-48710 that means the FastAPI-based gateway, vLLM server, or MCP server process is catalogued alongside its resolved Starlette version and the agents and CLIs that route through it, so you can answer "which endpoints run a service on Starlette before 1.0.1, and what talks to it" from the fleet inventory instead of guessing from a dependency manifest.

On agents that expose a hook, such as Claude Code PreToolUse, Anomity returns allow, deny, or log on each tool call before it runs. That is the enforcement point in runtime governance: a tool call that routes to a gateway or MCP server you have flagged as carrying an unpatched Starlette can be denied or logged in line rather than discovered after the fact. Anomity collects metadata only and redacts secrets on the endpoint, so it never has to read the credentials a chained exploit would be after.

Every decision is written to a queryable 90-day audit trail. After a disclosure like BadHost, that trail is what lets responders scope the event: which agents called through an affected service, when, and what each call was allowed to do. Anomity routes those decisions to SIEM, Slack, email, or Jira so the right team sees them in the tool they already use. The result is the timeline and the enforcement record described under outcomes.

Anomity complements your existing Network, EDR, DLP, and GRC controls rather than replacing them. It adds the agentic-endpoint layer those tools cannot see. See how it works and how Anomity compares for where it fits, and the agentic AI governance guide for the broader program.

What to check across your fleet

• Identify every AI service built on FastAPI, vLLM, LiteLLM, or an MCP server framework, and record the resolved Starlette version at runtime; treat anything before 1.0.1 as affected.
• Upgrade Starlette to 1.0.1 or later, which validates the Host value before reconstructing request.url, then rebuild and redeploy the affected images.
• Patch any application-layer CVE that chained with BadHost, including the LiteLLM RCE tracked as CVE-2026-42271, rather than relying on the Starlette fix alone.
• Audit middleware that makes authorization decisions on request.url.path, since a path-prefix check is the control BadHost defeats.
• Constrain accepted Host headers at the edge (reverse proxy or ingress) so malformed values containing /, ?, or # are rejected before reaching the application.
• Review access logs for requests carrying unusual Host header values around and after the deployment of affected builds, and for unexpected reach to protected routes.
• Enumerate which AI agents, CLIs, and MCP servers were configured to route through an affected service, using a fleet-wide AI artifact inventory.
• Confirm hook-based allow/deny/log enforcement is active on agents that route model traffic, so calls to a service on a vulnerable Starlette can be blocked.

CVE-2026-48710 shows how one flaw in a shared dependency reaches across an entire fleet of AI gateways and MCP servers at once, which is exactly why the AI artifact layer needs its own inventory and enforcement. For the full cluster context, see the pillar on securing LLM gateways and proxies. To see Anomity inventory your agents, govern tool calls at the hook, and keep a 90-day audit trail, request early access.