ANALYSIS · 306ea06f· FINISHED 2026-05-27 · PATCHDIFF

starlette-badhost1.0.0 → 1.0.1✓ COMPLETED

Files4

Vulnerable2

True positives2

CVE matched2

1 CVE article ready PatchLeaks generated full security writeups for the matched CVEs · one per CVE, with affected files linked

CVE-2026-48710

FILTERS 0

SEARCH

STATUS

JUDGE

CVE MATCH

EXTENSION

CWE

OPTIONS

Hide “No vulnerability” Hide unjudged

SCOPE

All 4 CVE 2 Vuln 2

SORT

2 files · page 1/1

starlette/datastructures.py

AI: 1 vulnerabilities

CVE-2026-48710 1 TP

#%!d(float64=002)

tests/test_datastructures.py

AI: 1 vulnerabilities

CVE-2026-48710 1 TP

#%!d(float64=003)

1–2 of 2

⌖

Select a file from the list to inspect its diff and AI analysis.

↑ ↓ to navigate

CVES 1

CVE-2026-48710

Security writeup for CVE-2026-48710

✓ 2 FILES

## 1. Vulnerability Background

What is this vulnerability?

- CVE-2026-48710 is a Host header validation bypass in Starlette, a lightweight ASGI framework/toolkit for Python.
- In vulnerable versions, Starlette reconstructed `request.url` from the incoming HTTP `Host` header without validating that header against the grammar defined by RFC 9112 §3.2 / RFC 3986 §3.2.2.
- Because routing uses the raw ASGI `scope["path"]` while `request.url` is rebuilt from the potentially attacker-controlled `Host` header, the two values could diverge.

Why is it critical/important?

- `request.url` is frequently used by middleware and endpoint logic for security decisions, access control, redirects, and canonicalization.
- If an attacker can cause `request.url.path` to differ from the actual requested path, security checks based on `request.url` can be bypassed even though the request is routed to the intended endpoint.
- This is a logic flaw in request normalization and host header handling, not just a parsing bug.

What systems/versions are affected?

- Starlette versions prior to 1.0.1 are affected.
- The issue is fixed in Starlette 1.0.1 and later.
- Applications using vulnerable Starlette releases and relying on `request.url` for security-sensitive path or host logic are at risk.

## 2. Technical Details

Root cause analysis

- In `starlette/datastructures.py`, `URL` construction used:
  `url = f"{scheme}://{host_header}{path}` when `host_header` was present.
- The host header was accepted without grammar validation.
- When `host_header` contained characters like `?`, `#`, `/`, `@`, `\`, or space, the resulting URL string could be parsed such that the effective path component changed.
- The routing engine still used the original ASGI `scope["path"]`, so the raw request path and reconstructed `request.url.path` could diverge.

Attack vector and exploitation conditions

- An attacker sends an HTTP request with a malicious `Host` header to an application running vulnerable Starlette.
- Exploitation requires the application to:
  - use Starlette <1.0.1,
  - accept the custom Host header,
  - and make security decisions based on `request.url` rather than the raw scope path.
- Example malicious host values from the test suite include:
  - `foo/?x=`
  - `foo/#`
  - `foo/bar`
  - `user@foo`
  - `foo\bar`
  - `foo bar`

Security implications

- A malformed Host header can alter `request.url.path` while leaving the raw path unchanged.
- Middleware or endpoint code that checks `request.url.path` can be tricked into wrong conclusions.
- This can lead to bypass of:
  - path-based access controls,
  - URL-based security filters,
  - redirect and canonicalization logic,
  - host-specific routing or validation.
- The vulnerability is primarily an authorization/information flow bypass rather than remote code execution.

## 3. Patch Analysis

What code changes were made?

- Added host validation with a regular expression in `starlette/datastructures.py`:
  `_HOST_RE = re.compile(r"^([a-z0-9.-]+|\[[a-f0-9]*:[a-f0-9.:]+\])(?::[0-9]+)?$", re.IGNORECASE)`
- Updated URL reconstruction logic to only use `host_header` if it matches the regex:
  `if host_header is not None and _HOST_RE.fullmatch(host_header):`
- If the host header is invalid, the code falls back to `scope["server"]` instead of using the malformed header.

How do these changes fix the vulnerability?

- The regex enforces valid host syntax before incorporating the attacker-controlled header into `request.url`.
- Invalid Host headers are ignored for URL reconstruction.
- This removes the ability of malformed Host values to inject path/query delimiters into the reconstructed URL.
- The fallback to `scope["server"]` ensures a trusted host/port source is used whenever the incoming header is invalid.

Security improvements introduced

- Host header handling now conforms to the expected RFC host grammar.
- `request.url` becomes consistent with the actual request path when the client supplies invalid host input.
- The patch closes the gap between raw ASGI path routing and reconstructed URL-based security logic.
- Added regression tests explicitly cover invalid Host headers and verify fallback behavior.

## 4. Proof of Concept (PoC) Guide

Prerequisites for exploitation

- Starlette version prior to 1.0.1.
- A Starlette application that:
  - exposes a protected route,
  - uses `request.url` in middleware or endpoint logic,
  - and does not separately validate the raw scope path.
- Ability to send custom `Host` headers.

Step-by-step exploitation approach

1. Deploy a vulnerable Starlette application.
2. Create or identify middleware that checks `request.url.path` or similar values for authorization.
3. Send an HTTP request to a protected path, e.g. `/admin`, with a malicious Host header such as:
   `Host: foo/?x=`
4. Observe the reconstructed `request.url` and `request.url.path`.

Expected behavior vs exploited behavior

- Expected behavior on a secure system:
  - raw request path `/admin`
  - reconstructed `request.url.path` == `/admin`
  - security checks based on `request.url` and `scope["path"]` agree
- Exploited behavior on vulnerable Starlette:
  - raw scope path remains `/admin`
  - reconstructed `request.url` may parse as `http://foo/?x=/admin`
  - `request.url.path` becomes `/`, or otherwise differs from the actual path
  - security checks based on `request.url` can be bypassed or misapplied

How to verify the vulnerability exists

- Reproduce with a vulnerable Starlette installation.
- Send a request with an invalid Host header and log both:
  - `scope["path"]`
  - `request.url.path`
- If they differ due to the Host header value, the issue is present.
- On patched versions, invalid Host headers are ignored for URL construction and `request.url.path` matches the raw path.

## 5. Recommendations

Mitigation strategies

- Upgrade Starlette to version 1.0.1 or later.
- Do not rely solely on `request.url` for security-sensitive path or host decisions.
- Validate `Host` headers against RFC-defined host grammar at the earliest point of request processing.
- Prefer trusted data sources such as `scope["server"]` when the incoming `Host` header is malformed.

Detection methods

- Audit application code for use of `request.url`, `request.url.path`, or host-based security checks.
- Monitor logs for requests with suspicious host header values containing delimiters or illegal characters.
- Use automated scanners to detect Starlette versions <1.0.1.
- Add WAF/IDS rules to flag malformed Host headers like those containing `?`, `#`, `/`, `\`, spaces, or `@`.

Best practices to prevent similar issues

- Treat all client-controlled headers as untrusted input.
- Apply strict validation on headers used to reconstruct URLs or derive security decisions.
- Use framework-provided host validation and fallback paths where available.
- Whenever possible, base access control on canonical, server-side values rather than reconstructed request metadata.
- Keep framework dependencies up to date and pay attention to security patches for request normalization logic.

CVE CVE-2026-48710

PRODUCT starlette-badhost

AFFECTED ≤ 1.0.0

FIXED IN 1.0.1

STATUS Generated

Security writeup · CVE-2026-48710

Source files · 2

starlette/datastructures.py Linked

tests/test_datastructures.py Linked

↗ NVD