Act nowKnown exploited

Advisory · CVE-2026-48710

Starlette Host header flaw can bypass path-based auth checks

Starlette versions before 1.0.1 rebuild request.url from an unvalidated Host header, so middleware gating on the URL path can be bypassed with a crafted header.

Advisory published September 2, 2026Independent summary
Vendor
Kludex
Product
Starlette
Identifier / CWE
CVE-2026-48710
CWE-444
Action timing
Sep 23, 2026
ELI5

Explain it like I’m five

A restaurant checks your reservation name from the sign-in sheet but seats you from the number on your party's balloon. Write a fake number on the balloon and you get seated at a table that isn't yours.

SIMPLIFIED_ATTACK_PATH04 STEPS
  1. 01Crafted Host header

    An attacker sends a request whose Host header contains path characters like / or ?.

  2. 02Routing uses real path

    Starlette routes the request on the raw HTTP path, so the endpoint executes normally.

  3. 03URL rebuilt wrong

    request.url is reconstructed by re-parsing http://{host}{path}, so request.url.path reflects the injected characters instead of the real path.

  4. 04Checks bypassed

    Middleware or endpoints that gate access on request.url.path see the forged path and allow the request through.

What happened

CISA added CVE-2026-48710 to the Known Exploited Vulnerabilities catalog on September 2, 2026. The flaw affects Starlette versions before 1.0.1.

Starlette’s router dispatches on the raw HTTP path, but request.url is rebuilt by concatenating the Host header with the path and re-parsing the result. A Host value containing characters like /, ?, or # shifts the path/query boundaries during re-parsing, so request.url.path no longer matches the path that was actually requested. Any middleware or endpoint applying security restrictions based on request.url.path can therefore be bypassed, while the router still delivers the request to the real (protected) endpoint. Starlette 1.0.1 and later validate the Host header against the RFC 9112 / RFC 3986 host grammar when constructing request.url and fall back to scope["server"] for malformed values.

The issue was publicly analyzed by researchers (disclosed via OSTIF as “BadHost” and in X41 D-Sec advisory x41-2026-002). NVD data also shows the vulnerable library ships inside Red Hat products including OpenShift AI, Ansible Automation Platform, and Satellite, so exposure extends beyond direct Starlette deployments.

What to do

  1. Inventory Python services for the installed Starlette version and upgrade affected apps to 1.0.1 or later.
  2. Search codebases for middleware or endpoints that make security decisions from request.url or request.url.path rather than the raw scope path, and fix the checks.
  3. Confirm that fronting proxies reject or normalize malformed Host headers before forwarding, and that the app does not trust attacker-controlled headers such as X-Forwarded-Host elsewhere.
  4. Review HTTP access logs for requests with unusual Host values (containing /, ?, #) as possible probing.
  5. Check downstream platforms (Red Hat OpenShift AI, Ansible Automation Platform, Satellite) for vendor patches covering the bundled Starlette.

Management note

This is a subtle framework flaw that turns path-based authorization into a suggestion: the router and the security check look at two different versions of the same request. Because Starlette is embedded in many AI and automation platforms, exposure is likely wider than your Python service inventory suggests. Patch the library, but also audit which of your access controls actually depend on request.url.