The short answer
A dependency you probably don’t list can bypass your authentication. CVE-2026-48710 is an actively exploited flaw in Starlette, the lightweight ASGI toolkit that FastAPI is built on. Before Starlette 1.0.1, the framework rebuilt its request.url from the incoming HTTP Host header without validating it. A crafted header (for example, one containing a ?) can make request.url.path disagree with the path that routing actually matched. Any middleware that decides authorization from request.url.path can then be fooled into serving a protected endpoint to an unauthenticated caller. CISA added it to the Known Exploited Vulnerabilities catalog on September 2, 2026, and VulnCheck has linked it to ransomware activity. The fix is to upgrade to Starlette 1.0.1.
The reason this one is dangerous is not its CVSS 6.5 — it is that Starlette hides under FastAPI. Teams that inventory their API stack by top-level packages see “FastAPI” and move on, never noticing the vulnerable transitive dependency running in production. Medium score, hidden location, and real exploitation is a combination that gets skipped exactly when it should be patched first.
What the flaw actually is
Starlette is the compact ASGI toolkit that gives Python web apps routing, middleware, and request/response handling. It is used directly by some teams, but far more often it arrives as the foundation of FastAPI, which builds its ergonomics on top of Starlette’s primitives. That layering is the whole point of the framework — and the reason this vulnerability reaches so many services that never installed Starlette on purpose.
The bug is a mismatch between two different notions of “the path.” Starlette routes a request using the raw path from the HTTP request line, but it reconstructs the convenient request.url property partly from the Host header. Before version 1.0.1 that header was trusted without validation. By sending a malformed value — the disclosed example is a header like Host: foo? — an attacker can inject content that makes the rebuilt request.url.path come out different from the path routing actually matched. The advisory classifies this as HTTP request/response smuggling; in practice it means one request can present two different faces depending on which value your code reads.
That divergence becomes a security hole wherever authorization is decided from request.url.path. A common pattern is middleware that gates a prefix — “require a valid session for anything under /admin” — by inspecting request.url.path. If that reconstructed value can be steered to look like a public path while routing still dispatches the request to the protected handler, the check waves the request through and the protected endpoint runs without authentication. The flaw is rated CVSS 6.5, it was disclosed on May 27, 2026, and it is fixed in Starlette 1.0.1. Reachable, unauthenticated, and aimed at your access-control layer is exactly the class of issue a penetration test and security audit is meant to catch before someone else does.
Why a medium score is misleading here
On paper, CVE-2026-48710 is a medium-severity issue, and medium issues are the ones teams routinely park behind the critical-labeled headliners. That instinct is usually reasonable, but the CVSS number describes theoretical impact in isolation — it does not know that attackers are already using this flaw. CISA’s Known Exploited Vulnerabilities catalog does: it is populated from evidence of real-world exploitation, and it added this CVE on September 2, 2026, with a September 16 remediation deadline for US federal agencies. VulnCheck has separately reported the flaw’s use in known ransomware campaigns.
When the abstract severity score and the observed-exploitation signal disagree, the second one should usually win. A medium-scored authentication bypass that is being weaponized in the wild is more urgent than a critical-scored bug with no known exploitation, because the former is a problem you have today. This is a clean example of why patch prioritization based on CVSS alone leaves gaps: it under-weights exactly the flaws that are cheap to exploit and easy to overlook.
The second reason it matters is location. An authentication bypass in a package you explicitly installed is visible; you will find it the next time you scan direct dependencies. An authentication bypass in the library underneath the package you installed is not. Because FastAPI vendors Starlette as its runtime, plenty of teams have never listed Starlette in their requirements, so a top-level dependency scan reports a clean bill of health while the vulnerable code answers live traffic. Invisible plus exploited is the worst pairing on a risk register.
What it means for US & EU software teams
The first lesson is that your dependency inventory has to reach transitive packages, not just the ones you typed. Modern services are mostly code you did not write, pulled in several layers deep. A software bill of materials (SBOM) that only records direct dependencies will miss issues like this by construction. Generate SBOMs from your resolved lockfiles, keep them current, and be able to answer “which of our services ship Starlette, and at what version” in minutes rather than days.
The second lesson is that authorization should not hang on a reconstructed value. Deriving access decisions from request.url.path couples your security boundary to whatever quirks live in URL parsing and header handling. Prefer explicit, route-level authorization — a dependency or decorator attached to the protected route itself — over prefix checks in middleware that re-read a rebuilt path. Where you must inspect the path, use the raw routed value, and normalize or validate the Host header at your reverse proxy or API gateway so malformed hosts never reach the app.
Third, this is a compliance-relevant event, not just an ops ticket. For EU teams, DORA makes ICT third-party and component risk explicit for financial entities, and NIS2 raises the bar for essential and important services; for US teams in FinTech and health, an authentication bypass touches the access-control and integrity expectations baked into SOC 2 and HIPAA. Being able to show which services carried the vulnerable Starlette version, when you upgraded, and how you now enforce authorization is precisely the evidence auditors and regulators ask for after an exploited-in-the-wild flaw.
What to do now
- Find every Starlette instance, direct and transitive. Search resolved lockfiles and running images for Starlette across all Python services, including anything built on FastAPI. The versions you cannot see are the ones that stay vulnerable.
- Upgrade to Starlette 1.0.1 or later. Bump the pin, rebuild, and redeploy. For FastAPI apps, upgrade Starlette explicitly rather than assuming a FastAPI version bump carries the fix, and confirm the resolved version after the build.
- Harden the edge as defense in depth. Validate or normalize the
Hostheader at your reverse proxy, load balancer, or API gateway, and reject malformed hosts before they reach the application. - Stop authorizing from
request.url.path. Move access decisions to explicit route-level authorization, and where you must read the path, use the raw routed value rather than the reconstructed URL. - Treat KEV as your priority signal. Add CISA KEV membership and ransomware association to your patch-prioritization rules so exploited medium-severity flaws jump the queue ahead of unexploited critical ones, and add path-based auth bypass to your next penetration test scope.
Frequently asked questions
What is CVE-2026-48710?
It is an HTTP request/response smuggling vulnerability in Starlette, the ASGI toolkit that FastAPI is built on. Before version 1.0.1, Starlette did not validate the HTTP Host header before reconstructing request.url. A malformed header can make request.url.path differ from the path that was actually routed, so middleware that authorizes on request.url.path can be tricked into serving protected endpoints. It is rated CVSS 6.5 (medium).
Is CVE-2026-48710 being exploited?
Yes. CISA added it to the Known Exploited Vulnerabilities catalog on September 2, 2026, based on evidence of active exploitation, with a federal remediation deadline of September 16, 2026. VulnCheck has reported its use in known ransomware campaigns. The medium CVSS score does not reflect that real-world risk, so patch it as an emergency rather than deferring it.
Do I need to worry if I only use FastAPI?
Yes. FastAPI is built on Starlette, so a FastAPI app pulls Starlette in as a dependency even if nothing in your requirements file names it. That is what makes this easy to miss: an inventory that lists FastAPI often will not surface Starlette, so teams believe they are unaffected while the vulnerable code runs in production. Check the resolved Starlette version in every FastAPI service.
How do we fix it?
Upgrade Starlette to 1.0.1 or later in every service that depends on it, directly or through FastAPI, then rebuild and redeploy. As defense in depth, validate or normalize the Host header at your reverse proxy or API gateway, and avoid making authorization decisions from request.url.path alone — prefer the raw routed path and explicit route-level authorization.
Why is a medium-severity flaw on the CISA KEV list?
The KEV catalog is driven by evidence of real-world exploitation, not by CVSS score. A vulnerability earns a place when attackers are actually using it, whatever its rated severity. CVE-2026-48710 is a reminder that severity scores estimate impact in isolation, while KEV listing and ransomware association describe what is happening now — and that second signal should usually win when you prioritize patching.
Sources
CISA — Known Exploited Vulnerabilities Catalog: CVE-2026-48710 (Kludex Starlette HTTP Request/Response Smuggling)
The Hacker News — CISA Adds Seven Exploited Flaws as Attackers Deploy Reverse Shells and Crypto Miners
Snyk — HTTP Request Smuggling in starlette (CVE-2026-48710)