CVE-2026-48710 - Bad Hosts in the Wild
- May 29
- 5 min read
A census of the Starlette host-header auth bypass
Persistent Security - research writeup. Aggregate findings only; per-target detail is withheld pending the coordinated-disclosure window (public deadline 2026-08-26). Classification: TLP:AMBER.
2,856 findings (deduped) | ~2,393 confirmed vulnerable | 58 countries | ~78% fail-open (Tier 1) |
TL;DR
CVE-2026-48710 is a Starlette host-header authentication bypass. Because FastAPI is built on Starlette, the affected population spans applications of every kind - AI and non-AI - and that broad impact is only starting to unfold. Our scanning lens here is the AI infrastructure layer, where the flaw surfaces first and hits hardest: LiteLLM proxies, OpenAI-compatible gateways, and Model Context Protocol (MCP) servers. Across a ~50,000-host sample we confirmed ~2,393 vulnerable deployments (2,856 findings including high-confidence 'potentially vulnerable'), across 58 countries. The bypass needs a single unauthenticated HTTP request - no credentials, no brute force. About 80% of vulnerable deployments fail open: any injected path defeats the auth middleware.
This 50k-host sample is only a slice to illustrate the problem - it is currently unknown how many vulnerable hosts remain exposed exactly; the real number is very likely much higher given Starlette reports 325 million downloads per week. Every figure here is a lower bound.
Data provenance: Our numbers come from our own active scanning, not from people self-testing at badhost.org. Self-checks are never logged beyond an anonymized counter line that saves the verdict, type of bypass, number of probes, and timing (no IP, hostname, Host header, or path).
Findings (aggregate)
We found ~2,393 services confirmed vulnerable out of 50,000. That makes 2,856 findings total including potentially-vulnerable.
The vulnerable hosts span 2,175 unique IPs with 545 domains, across 58 countries. The geography is heavily concentrated: US 49% (1403), CN 23% (669), DE 7% (197) - top three ~79%, top ten ~90%.
~80% are Tier 1 (fail-open): the middleware allow-lists root or treats unknown paths as permitted, so any injected path works. Only a minority require a specific allow-listed path (Tier 2). Fail-open dominance is itself the headline - most of these were wide open by default.
Roughly half are self-hosted; the rest spread across a long tail of providers with no single cloud dominating - a configuration problem, not a provider problem.
Patch adoption
Because we rescan hosts days after first finding them vulnerable, we can measure adoption rather than guess. Across our largest cohort (1,984 previously-vulnerable hosts rescanned ~1–3 days later), 79% were still vulnerable. Only ~12% had patched or pulled the service, and ~8% were unreachable at recheck (some transient, not remediation).
Cohort | n | Still vulnerable | Patched / removed | Offline at recheck |
Initial vulnerable set (rechecked ~2 days later) | 451 | 87% | 8% | 5% |
Full vulnerable set (rescanned ~1-3 days later) | 1,984 | 79% | 12% | 8% |
Port-8000 set (rechecked ~1 day later) | 138 | 69% | 29% | 2% |
Read this as an early-window adoption rate: within the first days after discovery (and, where applicable, CSIRT/abuse notification), the large majority remain exploitable. A handful patched within 24 to 72h, which is an the exception.
The bug in three sentences
Starlette (< 1.0.1) derives request.url.path from the HTTP Host header. Applications that gate access with path-based middleware therefore check an attacker-controlled path instead of the real request path. Sending Host: target/?x= makes the middleware evaluate / (commonly allow-listed) while the request still reaches the protected endpoint.
Normal request Bypass request
----------------- -----------------
GET /v1/models HTTP/1.1 GET /v1/models HTTP/1.1
Host: target Host: target/?x=
-> 401 Unauthorized -> 200 OK (middleware saw "/")
This is not only an AI problem - it's where it surfaced first
CVE-2026-48710 is a Starlette bug, and FastAPI is built on Starlette - one of the most widely deployed Python web frameworks in the world. The potentially-affected population spans applications of every kind, AI and non-AI alike; any FastAPI/Starlette service that makes auth decisions in path-based middleware is a candidate. The broad impact across ordinary web services is only beginning to unfold. Our data skews toward AI for two reasons of discovery and deployment - not because only AI is affected:
MCP servers (~16%) are advertised and reachable by design - they exist to be called by agents - so they surface readily in scans. Bypass hands an attacker the same tool-call surface a trusted agent would have.
LiteLLM / OpenAI-compatible proxies (~80%) are built on FastAPI, deployed widely, and exposed as key-bearing gateways. Bypass reaches /v1/models, /v1/chat/completions and the admin surface (/key/info, /key/generate, /user/info, /team/info) - key disclosure, quota theft, tenant enumeration.
High, concrete impact today in MCP and LLM-proxy deployments; a much larger, still-unfolding exposure across all FastAPI/Starlette applications. RedHat has a good tracking of the impact on other projects here: https://access.redhat.com/security/cve/cve-2026-48710
Methodology
For this sample we sourced candidates from RIPE delegated stats and Censys/Shodan fingerprints for Uvicorn/Starlette. Additionally we added data acquired via zgrab2 pre-triage and keept hosts returning 401/403 only.
When then verified the issue with a 3-step pipeline:
Discover unauthenticated paths, confirm a protected endpoint
Attempt the Host-header bypass (root-absorb / prefix / query-absorb) on one endpoint to confirm the system is affected
Recheck the vulnerable set later for patch velocity.
No application data was exfiltrated in accordance with CVD principles.
What's actually exposed (anonymized)
From automated metadata-only verification of a subset of MCP servers, grouped by sector and capability we found the following exposed:
Sector | Likely Exposed | Worst-case impact |
Biopharma intelligence | clinical-trial / patent / M&A search, people search, URL fetch | PII exposure, SSRF |
Identity verification | internal RAG: face analysis, KYB, PII verification, source-code search | Identity-pipeline & source exposure |
IoT / device management | bastion: device list/status/exec + file transfer | Remote code execution |
Email automation | read / send / delete mail, export attachments | Mailbox takeover, exfiltration |
HR / applicant tracking | job listings, candidate records, pipeline stages | Candidate PII |
CMS / marketing | content approval, mass email campaigns, subscriber lists | Mass-mail abuse, PII |
Document management | search / read / upload documents | Confidential document access |
Cloud infra monitoring | service auditing, SLO, trace analysis | Internal topology disclosure |
Security tooling | asset discovery, vuln scanning, path probing | Abuse of offensive infra |
Personal / health tracking | nutrition, expense, subscription data | Health + financial PII |
Risk rollup (verified subset): remote code execution (1), email/messaging abuse (2–3), PII exposure (several sectors), SSRF (1), confidential-document access (1), internal-infrastructure disclosure (2), compute abuse (2+). Many ran on plaintext HTTP with no TLS.
Remediation
Upgrade Starlette to ≥ 1.0.1. This is the fix.
Normalize/validate the Host header at the edge (reverse proxy) as defense in depth.
Stop authenticating on request.url.path in middleware - move auth to endpoint-level dependencies (Depends() / Security()).
LiteLLM operators: upgrade, then rotate provider/admin keys - exposed keys must be treated as compromised.
Put a proxy in front of these services but make sure to disallow X-Forwarded-Host or other non standard headers from being passed and processed!
Tooling & detection
X41 D-Sec has published proof-of-concept and detection tooling - a Python scanner, CodeQL queries, and Semgrep rules to catch the underlying pattern (auth decisions based on request.url.path) in source review, not just at runtime:
Disclosure
We are working with national certs, in particular the Belgian CCB to notify affected entities through their national CSIRTs/CERTs and, for cloud-hosted systems, provider abuse channels (TLP:AMBER). This report is intentionally aggregate-only.
Methodology questions and CSIRT coordination: info@persistent-security.net
