Litestar: AllowedHostsMiddleware bypasses host validation via client-controlled X-Forwarded-Host header
Date: 2026-06
Affected: pip/litestar
Attack vector: other
Category: vulnerability-disclosure
Severity: Medium
CVE: CVE-2026-48061
CWE: CWE-348
CWE-807
CVSS: 5.9 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N)

### Summary `AllowedHostsMiddleware` trusts the `X-Forwarded-Host` header as a fallback when the `Host` header is absent. Since `X-Forwarded-Host` is a client-controllable header, an attacker can bypass the allowed hosts validation by omitting the `Host` header and supplying an `X-Forwarded-Host` header set to a whitelisted domain. This enables host header injection attacks such as password reset poisoning, cache poisoning, and server-side request routing manipulation. ### Details In `AllowedHostsMiddleware.__call__`, the host value used for validation is resolved as follows: https://github.com/litestar-org/litestar/blob/main/litestar/middleware/allowed_hosts.py#L68 ```python headers = MutableScopeHeaders(scope=scope) if host := headers.get("host", headers.get("x-forwarded-host", "")).split(":")[0]: if self.allowed_hosts_regex.fullmatch(host): await self.app(scope, receive, send) return ``` When `Host` is absent (e.g., HTTP/1.0 clients, misconfigured proxies, or raw TCP connections), the middleware falls back to `X-Forwarded-Host` without any verification that the request actually passed through a trusted reverse proxy. An attacker can send a request with no `Host` header and set `X-Forwarded-Host` to any whitelisted domain, bypassing the entire allowed hosts check. The application then processes the request as if it originated from a trusted host. This is particularly dangerous when applications use the resolved host value for: - Generating passwo


Mitigations:

Architectural layers (MAESTRO):