CVE-2026-54282: Starlette: Unvalidated request path concatenated into authority poisons request.url.hostname

Published Jun 15, 2026
·
Updated

Summary

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.

Details

When a client requests a path that does not start with /:

http GET @google.com HTTP/1.1 Host: localhost

affected versions reconstruct the URL as http://localhost@google.com. 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:

text request.url == "http://localhost@google.com" 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"].

Impact

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.

Mitigation

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".

Other sources

Starlette is a lightweight ASGI framework/toolkit. Prior to 1.3.0, 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. This vulnerability is fixed in 1.3.0.

MITRE

Affected Software

2 affected componentsFixes available
pip/Starlette<1.3.0
1.3.0
Encode Starlette python<1.3.0

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade pip/Starlette to a version that resolves this vulnerability.

    Fixed in 1.3.0
  2. Upgrade

    Upgrade Starlette to a version that resolves this vulnerability.

    Fixed in 1.3.0

Event History

Jun 15, 2026
Advisory Published
via GitHub·08:38 PM
Data Sourced
via GitHub·08:38 PM
DescriptionSeverityWeaknessAffected Software
Jun 22, 2026
CVE Published
via MITRE·04:45 PM
Data Sourced
via MITRE·04:45 PM
DescriptionSeverityWeakness
Data Sourced
via NVD·06:16 PM
DescriptionSeverityWeaknessAffected Software
Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

What is the severity of CVE-2026-54282?

CVE-2026-54282 has a severity rating of low, with a score of 3.7.

2

How do I fix CVE-2026-54282?

To fix CVE-2026-54282, ensure that the HTTP request path is validated before it is used to reconstruct request.url.

3

What types of systems are affected by CVE-2026-54282?

CVE-2026-54282 affects systems using pip/Starlette where HTTP request paths are not validated.

4

What are the main risks associated with CVE-2026-54282?

The main risks of CVE-2026-54282 include possible SSRF attacks due to improper input validation.

5

When was CVE-2026-54282 published?

CVE-2026-54282 was published on June 15, 2026.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203