Impact ranges from unauthenticated access to protected endpoints to possible chaining with other flaws, potentially enabling server-side request forgery or remote code execution in complex deployments; demonstrations show a single-character Host header change can shift responses from 403 to 200.

Mitigations include upgrading Starlette to 1.0.1 or later and patching the full dependency tree; avoid using request.url.path for authorization decisions and instead tie checks to endpoints via requires/Depends/Security; deploy edge filtering for malformed Host headers at proxies or WAFs; audit and rotate credentials if compromise is suspected; use scanners and code queries from X41 D-Sec and CISA to identify vulnerable paths.

Affected versions span from Starlette 0.8.3 to 1.0.0, with 1.0.1 delivering the fix that validates the Host header and falls back to the socket address for malformed values; downstream frameworks like FastAPI inherit the issue unless their Starlette dependency is updated; LiteLLM and other MCP server implementations on this stack are also affected.

Exploitation requires a specific setup: the app must rely on request.url or request.url.path for security decisions, there must be no in-front proxy/gateway normalizing the Host header, and the attacker must reach the server with a controlled Host header; protections bound to the actual endpoint (e.g., FastAPI Depends or Security) may not be bypassed by this path pollution alone.

The vulnerability exists because Starlette before 1.0.1 reconstructed request URLs by concatenating the client-supplied Host header with the request path and re-parsing it without validating Host against RFC standards, allowing Host values with URI delimiters to shift the perceived path boundary.

A critical authentication bypass in Starlette, tracked as CVE-2026-48710 and nicknamed BadHost, arises from malformed Host headers that can disrupt path authorization and potentially grant unauthenticated access to protected endpoints.