CVE-2026-54282Low· 3.7▾ SunlitStarlette: Unvalidated request path concatenated into authority poisons request.url.hostname
▾ Sunlit zone — Low / medium · no exploitation signal
impact 20.4 · likelihood 0 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Exploit-prediction probability, daily snapshots since Jul 7.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via OSV
0.2%
0.2% → 0.3%
Last analysed / modified upstream
In affected versions, the HTTP request path is not validated before being used to reconstruct request.url. Because request.url is rebuilt by concatenating {scheme}://{host}{path} and re-parsing the result, a path that does not begin with / (for example @google.com) moves the authority boundary during re-parsing, so request.url.hostname and request.url.netloc become attacker-controlled. Code that reads request.url.hostname (rather than the Host header or scope) can therefore be misled into trusting an attacker-supplied host.
When a client requests a path that does not start with /:
GET @google.com HTTP/1.1
Host: localhost
affected versions reconstruct the URL as http://[email protected]. Per RFC 3986 §3.2.1, the substring before @ in the authority is userinfo, so re-parsing yields username = "localhost" and hostname = "google.com", with an empty path:
request.url == "http://[email protected]"
request.url.hostname == "google.com"
request.url.path == ""
The root cause is that the path is concatenated directly after the host without a separating /, and without validating that it begins with one. Only the Host header was validated when constructing request.url; the path was not.
This requires an ASGI server that forwards a request-target lacking a leading / into scope["path"].
Any application running an affected version that uses request.url, request.url.netloc, or request.url.hostname for a security-sensitive decision (host-based authorization, redirect/callback base, SSRF target, cache key, audit log) may be affected, when no fronting proxy or load balancer rejects the malformed request-target first.
Note that this is less exploitable than GHSA-86qp-5c8j-p5mr: there, the poison is carried in the Host header, so the real path still routes to a valid endpoint while request.url.path lies. Here, the poison must be carried in the path itself, and that path (@google.com) does not match any registered route, so routing returns 404 and no endpoint handler runs. The exposure is limited to code that reads request.url before routing - notably middleware - or in 404/exception handlers.
Upgrade to a patched version, which prevents the request path from crossing into the URL authority. The request above instead yields http://localhost/@google.com with request.url.hostname == "localhost".
starlette < 1.3.0Upgrade to a patched release:
starlette 1.3.0Connected by shared product, vendor, weakness, or advisory.
CVE-2025-62727High· 7.5Starlette vulnerable to O(n^2) DoS via Range header merging in ``starlette.responses.FileResponse``
CVE-2026-48817Medium· 5.3Starlette: Arbitrary HTTP method dispatched to `HTTPEndpoint` attributes via `getattr`
CVE-2026-48818High· 7.5Starlette: SSRF and NTLM credential theft via UNC paths in StaticFiles on Windows
CVE-2026-48710Medium· 6.5Starlette is a lightweight ASGI framework/toolkit
CVE-2023-29159Low· 3.7Starlette has Path Traversal vulnerability in StaticFiles
CVE-2024-47874None· 0.0Starlette Denial of service (DoS) via multipart/form-data