Path Traversal in Starlette Framework

Executive Summary

The vulnerability CVE-2026-54282 affects Starlette versions prior to 1.3.0. It occurs because the HTTP request path is not properly validated before being used to reconstruct the request URL.

If the path does not start with a forward slash (for example, "@google.com"), it can manipulate the URL's authority section during re-parsing. This causes the values of request.url.hostname and request.url.netloc to be attacker-controlled.

Applications that rely on these values for security-sensitive decisions, such as host-based authorization, redirects, or SSRF checks, can be misled by an attacker.

The root cause is the direct concatenation of the path after the host without validation or a separating slash.

This vulnerability is fixed in Starlette version 1.3.0 and later, which prevents the path from crossing into the URL authority.

Useful 0 Not Useful 0

Compliance Impact

The provided information does not specify any direct impact of this vulnerability on compliance with common standards and regulations such as GDPR or HIPAA.

Useful 0 Not Useful 0

Impact Analysis

This vulnerability can impact applications that use Starlette by allowing an attacker to control the hostname and network location parts of the reconstructed request URL.

If the application relies on request.url.hostname for security decisions such as host-based authorization, redirects, or server-side request forgery (SSRF) protections, an attacker could bypass these controls.

However, the impact is somewhat limited because routing returns a 404 error for malformed paths, but middleware or exception handlers that read request.url before routing could still be affected.

To mitigate this risk, upgrading to Starlette version 1.3.0 or later is recommended.

Useful 0 Not Useful 0

Detection Guidance

This vulnerability involves the HTTP request path not being validated before reconstructing the request URL, allowing attacker-controlled manipulation of request.url.hostname and request.url.netloc if the path does not start with a forward slash.

To detect this vulnerability on your system, you can monitor or test for HTTP requests with paths that do not begin with a forward slash, such as paths starting with '@' or other characters, which could manipulate the URL authority.

Since the vulnerability is related to how the application processes incoming HTTP requests, you can use tools like curl or HTTP request interceptors to send crafted requests and observe the application's behavior.

• Use curl to send a request with a malformed path: curl -v http://yourserver/@google.com
• Check application logs or debugging output for unexpected values in request.url.hostname or request.url.netloc.
• If possible, add logging or debugging in middleware or exception handlers to capture and inspect request.url values before routing.

Useful 0 Not Useful 0

Mitigation Strategies

The primary and recommended mitigation is to upgrade Starlette to version 1.3.0 or later, where the vulnerability is fixed by preventing the path from crossing into the URL authority.

Until the upgrade can be applied, review your application code to avoid relying on request.url.hostname or request.url.netloc for security-sensitive decisions such as host-based authorization, redirects, or SSRF checks.

Consider validating or sanitizing the HTTP request path to ensure it always begins with a forward slash before it is used to reconstruct URLs.

Useful 0 Not Useful 0