An attacker can supply a request path that does not begin with a forward slash, causing Starlette to rebuild the request URL by concatenating scheme, host, and path before re‑parsing it. This sets the authority boundary incorrectly so that request.url.hostname and request.url.netloc are derived from the attacker‑supplied path rather than from the Host header. If application code trusts request.url.hostname—for authentication, routing, or security checks—it can be convinced of a forged host, enabling trust‑based attacks such as diverted request handling or credential reuse. The issue was addressed by validating the path before URL reconstruction in version 1.3.0.

All releases of the Kludex Starlette framework older than version 1.3.0 are affected. Any application that imports and uses Starlette and processes client requests without patching is potentially exposed.

The CVSS score of 3.7 indicates low severity, and the EPSS score is < 1%, indicating a negligible but non-zero exploitation probability, suggesting limited evidence of exploitation, as reflected in its absence from CISA KEV. However, the flaw can be triggered by a crafted HTTP request to the web application; it requires. Attackers would likely use remote HTTP traffic to send a path such as '@google.com/some/route', causing the framework to generate a URL whose hostname is attacker‑controlled. Because the vulnerability is not mitigated by network isolation, it could be effective against publicly exposed services that run older Starlette versions.