Does Starlette GHSA-86qp-5c8j-p5mr affect FastAPI installations using Starlette <= 1.0.0?

[ftnext]

First Check

• I added a very descriptive title here.
• I used the GitHub search to find a similar question and didn't find it.
• I searched the FastAPI documentation, with the integrated search.
• I already searched in Google "How to X in FastAPI" and didn't find any information.
• I already read and followed all the tutorial in the docs and didn't find an answer.
• I already checked if it is not related to FastAPI but to Pydantic.
• I already checked if it is not related to FastAPI but to Swagger UI.
• I already checked if it is not related to FastAPI but to ReDoc.

Commit to Help

• I commit to help with one of those options 👆

Example Code

from fastapi import FastAPI, Request
from fastapi.testclient import TestClient

app = FastAPI()


@app.get("/foo")
async def foo(request: Request):
    return {"path": request.url.path}


client = TestClient(app)

response = client.get(
    "/foo",
    headers={"host": "example.com/abc?bar="},
)

print(response.json())

assert response.json()["path"] == "/foo"

Description

This is not a new private vulnerability report. The upstream Starlette advisory is already public and fixed in Starlette 1.0.1:
GHSA-86qp-5c8j-p5mr

I would like to confirm the expected impact and guidance for FastAPI users.

FastAPI depends on Starlette, and Request / request.url behavior comes from Starlette. My understanding is that if a FastAPI environment resolves to starlette<=1.0.0, the same issue can affect FastAPI applications as well (as Example Code).

Specifically, with a malformed Host header such as Host: example.com/abc?bar=, an application using request.url.path for path-based checks may observe a path different from the actual routed path. In my local reproduction, the request is routed to /foo, but request.url.path can be affected when using the vulnerable Starlette version.

This is fixed by upgrading Starlette to 1.0.1 or higher, where malformed Host headers are ignored when constructing request.url.

Operating System

macOS

Operating System Details

No response

FastAPI Version

0.136.1

Pydantic Version

2.13.4

Python Version

3.14.3

Additional Context

I tested the behavior with both Starlette 1.0.0 and 1.0.1:

• With starlette==1.0.0, the malformed Host header can affect request.url.path.
• With starlette==1.0.1, request.url.path remains the actual routed path.

Again, this is about confirming FastAPI impact for an already public upstream Starlette advisory, not reporting a new undisclosed vulnerability.

[CarlosOliveira-23]

Hi @ftnext — your analysis is correct.
Since FastAPI delegates all Request / request.url handling to Starlette, any FastAPI application running on Starlette ≤ 1.0.0 is exposed to the same issue described in GHSA-86qp-5c8j-p5mr (CVE-2026-48710).
Root cause (from the advisory): Affected versions reconstruct request.url by concatenating http://{host}{path} and re-parsing the result. When the Host header contains characters invalid per RFC 9112 §3.2 — such as /, ?, or # — the re-parsing shifts the path/query boundaries. This means request.url.path can return a different value than the path the router actually dispatched to. Your example reproduces this exactly: the request is routed to /foo, but request.url.path reflects /abc from the malformed header.
Who is at risk: Any FastAPI application that uses request.url.path (or request.url) for security-sensitive decisions — such as middleware enforcing path-based authorization — may be bypassed by an attacker sending a crafted Host header. Deployments behind a proxy that strips or normalizes malformed Host headers are partially mitigated, but you cannot rely on this unless it is explicitly guaranteed.
Recommended action: Upgrade Starlette to 1.0.1 or higher. The fix validates the Host header against RFC 9112 §3.2 / RFC 3986 §3.2.2 and falls back to scope["server"] for malformed values, so request.url.path will always reflect the actual routed path regardless of what the client sends in the Host header.
You can verify your environment with:
pip show starlette | grep Version
FastAPI 0.115.x and later should pull Starlette 1.0.1+ automatically, but pinned or transitive dependency setups may not — so an explicit check is worthwhile.
Thank you for the clear write-up and for confirming the reproduction!

[ftnext]

Thanks, this answers my question.

I understand this as an upstream Starlette issue that also affects FastAPI applications when the resolved Starlette version is <=1.0.0, especially if the application uses request.url.path or request.url for security-sensitive path-based checks.

The mitigation is to ensure Starlette is upgraded to >=1.0.1.

I’ll mark this as the answer.

[david-george-axomic]

Would it be worth updating the fastapi dependency Starlette>=1.0.1?

[YuriiMotov]

No. The intention is to let users use latest FastAPI version even if they can't upgrade to latest Starlette version.
So, it's the responsibility of app developer to upgrade dependencies to latest versions if possible