Starlette has missing Host header validation that poisons request.url.path, bypassing path-based security checks
Patch now. It under exploitation confirmed by CISA and has a working public exploit.
Official vendor statements in CSAF/VEX format: whether their product is affected, already fixed, or ruled out — and why. These are the vendor's assertions, not Vexday's judgment.
Apply mitigations in accordance with vendor instructions, ensuring compliance with CISA’s BOD 26-04 Prioritizing Security Updates Based on Risk (see URL in Notes) guidance and CISA’s “Forensics Triage Requirements” (see URL in Notes). Follow applicable BOD 26-04 guidance for cloud services or discontinue use of the product if mitigations are unavailable. Stakeholders are responsible for evaluating each asset's internet exposure and ensuring adherence to BOD 26-04 patching guidelines.
Starlette didn't properly validate the HTTP Host header, allowing attackers to craft malicious requests that make the URL path appear different from what was actually requested. This could bypass security checks that rely on the URL path.
The vulnerability exists in Starlette versions before 1.0.1 where the Host header is used to reconstruct request.url without RFC 9112/3986 validation. An attacker can send a malformed Host header to cause request.url.path to diverge from the actual routing path in scope, allowing bypass of path-based security middleware and endpoint restrictions that check request.url instead of raw scope values.