CVE-2026-54282: Starlette Path Traversal Vulnerability

CVE-2026-54282 Overview

CVE-2026-54282 affects Starlette, a lightweight Asynchronous Server Gateway Interface (ASGI) framework and toolkit used widely in Python web applications. Versions prior to 1.3.0 fail to validate the HTTP request path before reconstructing request.url. The framework rebuilds the URL by concatenating {scheme}://{host}{path} and re-parsing the result. A crafted request path that does not begin with / shifts the authority boundary during re-parsing, allowing an attacker to control request.url.hostname and request.url.netloc. Application code that trusts request.url.hostname instead of the Host header or ASGI scope can be misled into trusting an attacker-supplied host. The issue is categorized under [CWE-706] (Use of Incorrectly-Resolved Name or Reference) and is fixed in Starlette 1.3.0.

Critical Impact
Attacker-controlled hostnames in request.url can mislead downstream logic, including redirect generation, cache key construction, and access control decisions tied to the URL host.

Affected Products

Starlette ASGI framework versions prior to 1.3.0
Downstream frameworks built on Starlette (for example, FastAPI) that read request.url.hostname or request.url.netloc
Python web applications using Starlette routing that derive trust from reconstructed URLs

Discovery Timeline

2026-06-22 - CVE-2026-54282 published to NVD
2026-06-22 - Last updated in NVD database

Technical Details for CVE-2026-54282

Vulnerability Analysis

Starlette constructs request.url lazily by combining the URL scheme, host, and path strings and then re-parsing the concatenated value. The reconstruction logic assumes the request path begins with the / character, which is the normative form for HTTP request targets per RFC 9112. When the path lacks a leading slash and instead begins with a value such as @google.com, the resulting string http://victim.example.com@google.com is parsed as a URL whose authority component is victim.example.com@google.com. The @ character delimits userinfo from host, so the parser treats google.com as the hostname.

The vulnerability allows an attacker to coerce request.url.hostname to an arbitrary value while the underlying ASGI scope still routes the request to the original server. The Exploit Prediction Scoring System (EPSS) currently estimates a low probability of in-the-wild exploitation.

Root Cause

The root cause is missing input validation on the request path before string concatenation and URL re-parsing. Starlette does not assert that the path component starts with / or reject paths containing characters that change URL parsing semantics. The defect is a name resolution error [CWE-706] because the reconstructed URL resolves to a different authority than the actual request target.

Attack Vector

An attacker sends an HTTP request whose request-target does not begin with /. ASGI servers that forward the raw path into the Starlette scope expose downstream application code to the malformed value. Any handler that reads request.url.hostname, request.url.netloc, or builds links from str(request.url) will operate on attacker-controlled host data. Practical impact depends on how the application uses the value, including open redirect, cache poisoning, host-based authorization bypass, and link injection in generated content or emails.

The vulnerability requires network access to the application and a path-handling permissive front-end. No authentication or user interaction is needed. See the GitHub Security Advisory GHSA-jp82-jpqv-5vv3 for the maintainer's technical writeup.

Detection Methods for CVE-2026-54282

Indicators of Compromise

HTTP access logs containing request paths that do not begin with /, such as values starting with @, //, or arbitrary hostnames
Application logs showing request.url.hostname values that differ from the configured server Host
Outbound links, redirects, or email content referencing unexpected external domains generated from request URLs

Detection Strategies

Parse web server and reverse proxy access logs for request targets that fail the ^/ prefix check
Compare request.url.hostname to the ASGI scope server value or the validated Host header during request processing and alert on mismatches
Add instrumentation to the Starlette middleware chain that records the raw scope["path"] value for anomaly review

Monitoring Recommendations

Monitor for spikes in 4xx responses tied to malformed request targets at the edge proxy
Track inventory of Python services running Starlette versions below 1.3.0, including transitive dependencies pulled in by FastAPI and other frameworks
Review redirect and link-generation code paths in application telemetry for outbound destinations outside the allowlist

How to Mitigate CVE-2026-54282

Immediate Actions Required

Upgrade Starlette to version 1.3.0 or later across all environments
Audit application code for any use of request.url.hostname, request.url.netloc, or str(request.url) in trust decisions
Replace untrusted URL host reads with validated values from the ASGI scope or an allowlisted Host header

Patch Information

The maintainers fixed the issue in Starlette 1.3.0 by validating the request path before URL reconstruction. Refer to the GitHub Security Advisory GHSA-jp82-jpqv-5vv3 for commit references and version metadata. Applications using FastAPI or other Starlette-dependent frameworks should rebuild their dependency lockfiles after upgrading.

Workarounds

Configure the upstream reverse proxy or ASGI server to reject HTTP requests whose request-target does not begin with /
Add a Starlette middleware that inspects scope["path"] and returns HTTP 400 when the value lacks a leading slash
Derive hostnames from a server-side configuration value or a validated Host header allowlist rather than from request.url

bash

# Upgrade Starlette to the fixed release
pip install --upgrade "starlette>=1.3.0"

# Verify the installed version
python -c "import starlette; print(starlette.__version__)"