BADHOST

OSTIF is disclosing the expanded details of the BadHost vulnerability in Starlette as slow uptake of updated versions of Starlette and discovery of more vulnerable live services has caused us serious concerns.

I’d like to open by saying that the maintainer of Starlette is having a bad few weeks. This disclosure + patch process has been long and a lot of parties have been contacting them about this while they are simultaneously dealing with a large pile of other security reports that every open source project is dealing with in 2026. This bug is a classic “responsibility gap” where if this maintainer didn’t patch, thousands of exposed projects would have to individually secure their projects. In doing this work, they’ve voluntarily taken on the responsibility to protect the ecosystem from long-term systemic harm. As with all open source projects, they owed us nothing and could have left this to be everyone else’s problem and took the extraordinary steps of helping the ecosystem. Please consider donating to Kludex: https://github.com/sponsors/Kludex

What is BadHost? https://www.secwest.net/starlette

A lack of input sanitization on host header paths in Starlette leads to bypassing auth with a single character across a huge swath of Python LLM infrastructure. This hits very large and prominent projects such as FastAPI, LiteLLM, vLLM, text generation inference projects, most OpenAI shim proxies, MCP servers, Agent harnesses, eval dashboards and model-management UIs.

Identified as CVE-2026-48710 information is still propagating about this bug.
https://security-tracker.debian.org/tracker/CVE-2026-48710
https://osv.dev/vulnerability/DEBIAN-CVE-2026-48710
https://github.com/Kludex/starlette/security/advisories/GHSA-86qp-5c8j-p5mr (rating severely understates the severity of the bug downstream)

Starlette reconstructs request.url by concatenating the HTTP Host header with the request path and re-parsing the result. The Host value is not validated against the RFC 9112 / RFC 3986 grammar before reconstruction. A Host header containing /, ?, or # shifts the path, query, and fragment boundaries during re-parse, so request.url.path no longer matches the path the ASGI server actually received and routed against.

The router dispatches on the real wire path. Middleware sees the poisoned, re-parsed path. Any path-based security decision made in middleware can be bypassed while the underlying route still executes.

How bad is this?

A minimal POC:
curl -i -H ‘Host: foo’ http://target/admin # 403, blocked
curl -i -H ‘Host: foo?’ http://target/admin # 200, served

Where Starlette-based middleware (including FastAPI middleware) enforces authorization or routing restrictions using request.url or request.url.path, the following should be assumed reachable by an unauthenticated remote attacker:

Bypass of path-prefix authentication (/admin, /v1/models, /internal, /metrics, /shutdown, tool-execution endpoints)
Bypass of tenant or workspace scoping enforced in middleware
Smuggling of requests into endpoints intended to be reachable only from authenticated sessions or internal hops
SSRF against cloud metadata services and internal hosts where the gated endpoint performs outbound fetches
RCE where the gated endpoint exposes tool execution, plugin loading, arbitrary model loading from URL, file upload, or code-eval style functionality

For LLM gateways specifically, the admin and key-management surface of services like LiteLLM, and the model and runtime control surface of services like vLLM, must be treated as exposed if the deployment is direct-to-ASGI.

How widespread is this?

This affects vLLM, LiteLLM, and FastAPI and many many more. These projects collectively make up the vast majority of all Python LLM infrastructure today.

Test for this Vulnerability

BadHost.org has tooling to examine your infrastructure and determine if it is vulnerable. The BadHost project, run jointly by X41 D-Sec, Persistent Security Industries, and Bintech, offers a free remote scanner for any reachable HTTP endpoint at badhost.org. Suitable for quick triage of a few services.

X41 has also published a scanner, Semgrep rules, and CodeQL queries at Github.com/x41sec/poc/tree/master/starlette-host-header. Run these across any Python codebase that touches Starlette or FastAPI to find affected middleware patterns. The repository also includes a runtime PoC for confirming exposure on a deployed instance.

If you don’t want to use tooling, you are likely exposed if ANY of the following are true:

You run any FastAPI or Starlette application directly on uvicorn, hypercorn, daphne, or granian without an HTTP/1.1-compliant reverse proxy in front.
You run LiteLLM, vLLM, or similar LLM proxies and servers as the directly-reachable HTTP endpoint.
You terminate HTTP/3 or QUIC at a frontend whose Host validation behavior you have not verified.
Your application reads request.url.path in any authentication, authorization, audit, rate-limiting, or routing-decision code.
Any internal-only service is reachable from a workstation, VPN subnet, lab network, or other “we trust this network” segment.

Mitigation

Update to Starlette 1.0.1 as soon as possible.
Rebuild and redeploy every container, virtualenv, and bundled artifact that pins or vendors Starlette. Bundled installs are common in LLM tooling; pip list on the host is not enough. Audit images.

Replace request.url and request.url.path with request.scope[“path”] in every middleware, dependency, and decorator that makes security decisions. Grep the codebase. This bug class will recur; reading the un-reconstructed value is the durable fix.
Place a reverse proxy that rejects malformed Host headers in front of every ASGI-served application. nginx, Apache httpd, and Cloudflare reject the PoC by default. Verify your specific config.
For HTTP/3-terminated frontends, test Host header handling explicitly with the X41 PoC before relying on the proxy as a mitigation.

This bug was discovered through manual analysis by a senior security expert at X41 D-Sec during a security audit of vLLM managed by OSTIF.org that was sponsored by the Alpha-Omega Project. Our continued efforts to analyze downstream affected projects and notify everyone exposed was sponsored in part by Amazon Web Services.