CVE-2026-48710

Think of Starlette as the “traffic controller” for web requests in Python apps. This issue lets an attacker send a fake “address label” (the Host header) so Starlette builds the request URL in a misleading way.
If your app’s security rules look at that built URL path, the attacker can slip around those rules—like walking past a door guard by making them read the wrong sign.

This matters if you run or deploy Starlette-based Python web applications, or products that bundle Starlette—especially when they are internet-facing and use path-based checks based on request.url. The flaw is reachable in default configuration and does not require an attacker to be logged in.
Reachability gate: it’s a risk when the vulnerable code path is accessible over the network to an attacker (especially from the public internet) and the app uses request.url-based security restrictions (rather than the raw request path).

This is RED because it is confirmed in CISA KEV and listed with a specific CISA remediation due date (2026-09-16). Attackers can exploit it without authentication by sending a crafted Host header to poison how the app reconstructs request.url.path, letting them bypass path-based security checks.

1. Inventory and version check

   • Locate where Starlette is used in your environment (your Python app dependencies, and any embedded Starlette in ai inference server, ansible automation platform, migration toolkit for applications, openshift ai, openshift lightspeed, satellite, or enterprise linux ai).
   • Record exact installed versions.

2. Determine whether your app is exposed to the specific bypass

   • Look for middleware or endpoint logic that makes access decisions using request.url or request.url.path.
   • If you only check the raw ASGI scope path and never rely on request.url, risk may be reduced; if you do rely on request.url, treat as exposed.

3. Upgrade to fixed versions (primary remediation)

   • Upgrade Starlette to 1.0.1 or later.
   • If applicable to your environment: upgrade migration toolkit for applications to 8.2.0.
   • If applicable to your environment: upgrade openshift ai to 3.3.5.

4. CISA guidance and timing

   • This CVE is in CISA KEV (added 2026-09-02) with a remediation due date of 2026-09-16.
   • Apply mitigations in accordance with vendor instructions, and follow CISA’s prioritization and triage requirements noted in the KEV entry.

5. Temporary workaround while patching (if upgrade is delayed)

   • Reduce exposure: limit which external networks can reach these services (network allowlists / firewall rules).
   • Avoid keeping the service broadly accessible on the public internet.
   • If there is an application configuration toggle related to Host/header handling, ensure it is set to safely validate Host; otherwise, rely on network restriction until upgraded.

6. What to monitor after upgrade

   • Monitor web access logs for unusual Host header patterns targeting URL-based routes.
   • Confirm the service responds as expected for normal requests and that security middleware decisions are based on the correct request path behavior.

Severity is effectively treated as high operational risk in this case due to CISA KEV listing and active exploitation signals in traffic. The mechanism is Host header poisoning: prior to Starlette 1.0.1, Host was not validated before reconstructing request.url, allowing request.url.path to diverge from the actual requested path. If middleware or authorization logic uses request.url.path for path-based security controls, an attacker can bypass them.

Weakness mapping: CWE-444 (Inconsistent Interpretation of HTTP Headers) and CWE-1289 (Improper Validation of Specified Input).

KEV: Yes—listed by CISA, added 2026-09-02, with a due date of 2026-09-16.

Exploit maturity: public exploit details are not provided in the findings; however, the issue is described as being exploited in practice (PULSE and KEV indicate real-world risk). EPSS is provided as a prediction and should not be used as justification to delay response once KEV is present.