BadHost - CVE-2026-48710 Starlette Host-Header Auth Bypass

BadHost CVE-2026-48710

Also known as:
X41-2026-002
/
GHSA-86qp-5c8j-p5mr
/
PYSEC-2026-161

Discovered by X41 D-Sec during an OSTIF-sponsored audit
Scanner & automation by Nemesis

Critical severity.
Starlette < 1.0.1 derives request.url from the
Host header without sanitization, letting attackers
forge a request.url.path that bypasses path-based
auth middleware.
Thousands of FastAPI and Starlette applications are affected,
including vLLM, LiteLLM, MCP servers, and AI agent frameworks.

Full AI Infrastructure Scan
MCP Server
Custom

Automatically discovers MCP endpoints and common inference
API paths (vLLM, LiteLLM, OpenAI-compatible). Best for scanning AI
infrastructure where the exact stack is unknown.

Scan

powered by Nemesis security automation

Scans MCP servers only.
Probes standard MCP endpoints (/mcp, /sse,
/messages and variants) for auth-protected JSON-RPC, then
attempts Host-header bypass.

Scan

Advanced

Any Starlette or FastAPI application with path-based auth middleware is
affected. Select a preset or specify your own paths.

vLLM
/v1/models

LiteLLM
/model/info

LiteLLM Admin
/key/info

Custom
your own paths

Scan

How to fix

Update Starlette to version 1.0.1 or later, which
ignores Host headers containing invalid characters instead
of using them for URL construction.
Avoid path-based auth middleware. Middleware that
decides authentication based on request.url.path is inherently
fragile — auth should be tied to the endpoint itself, not the path
used to reach it. Prefer Starlette's
requires() decorator
or FastAPI's, Depends() and Security()
which are enforced on actual endpoints instead of a path-based middleware.
Deploy a reverse proxy (nginx, Caddy, Traefik, HAProxy) in
front of your ASGI server. RFC-compliant reverse proxies validate and normalize
the Host header before forwarding, which neutralizes this attack.
ASGI servers pass the raw header through to the framework — a reverse proxy
prevents that.
Use scope["path"] instead of
request.url.path if you must use middleware. The ASGI scope
path comes from the HTTP request line and cannot be manipulated via the
Host header.

What is BadHost / CVE-2026-48710?

Starlette < 1.0.1 builds request.url by concatenating the HTTP
Host header with the request path. An attacker can send a crafted
request like GET /protected with a Host: example.com/health?x=
header. The request will reach the /proteced path, but request.url
would be https://example.com/health?x=/protected, and request.url.path
would return /health instead of the real request path.
Any middleware that uses this value to decide whether to enforce authentication can be bypassed.

More details can be found in the X41-2026-002
advisory.

Which projects are affected?

Any Python application built on Starlette or FastAPI that uses
starlette < 1.0.1
and uses request.url (or starlette.datastructures.URL(scope=...))
in a middleware to make security decisions based on its path
(e.g. allowlists, denylists, CSRF exemptions, rate limiting, payment gates),
and runs on any ASGI server (Daphne, Granian, Gunicorn, Hypercorn, Anycorn, Uvicorn).
Use the scanner above, grep your codebase for request.url.path
in middleware files, or try the tools from the
X41
open-source repository.
This includes LLM inference
servers like vLLM, LLM proxy servers like LiteLLM, AI agent frameworks,
MCP gateways, and custom APIs. MCP servers are especially at risk because
the MCP spec mandates unauthenticated OAuth discovery endpoints, providing
a reliable path for exploitation

What about AI infrastructure (LLM proxies, agent frameworks)?

This vulnerability is not specific to LLMs, but many LLM inference servers
(vLLM), LLM proxy servers (LiteLLM), AI agent frameworks, and MCP gateway
implementations are built on FastAPI/Starlette
and use path-based auth to protect API endpoints. A bypass can expose model
access, API keys, and internal tooling. Google ADK-Python, Ray Serve, and
BentoML also use Starlette middleware and are potentially affected when
custom auth middleware is added. Any custom MCP server, FastMCP integration,
or AI agent backend using Starlette routing with auth middleware should be
tested. Note: FastAPI's built-in Depends() security uses route
matching, not request.url.path, so standard dependency-injection
auth is safe — the risk is in custom BaseHTTPMiddleware
or raw ASGI middleware.

Does a reverse proxy protect me?

Yes. RFC-compliant reverse proxies (nginx, Caddy, Traefik, HAProxy) validate
and reject invalid Host headers, which neutralizes
the injection. However, many deployments — especially dev, staging, and
self-hosted instances — expose ASGI servers directly without a proxy.

How does the scanner work?

The scanner first confirms a protected endpoint denies
access without credentials. Tier 1 then tests whether the middleware uses a
denylist (fail-open) pattern by injecting a random path into the Host
header — this catches misconfigured middleware in just a few requests.
If Tier 1 fails, Tier 2 discovers known unauthenticated paths and injects
those for allowlist-based (fail-closed) middleware. Raw TCP sockets are used
because standard HTTP clients normalize the Host header, which would prevent
the test.

Why didn't Mythos find this?

Anthropic's Claude Mythos found 10,000+ vulnerabilities through Project
Glasswing — but not this one. The reason is structural: CVE-2026-48710
is not a bug in one file or one repo. It spans three independent layers
— ASGI servers pass the raw Host header, Starlette trusts it for URL
construction, and middleware authors assume request.url.path is
safe for auth decisions. Each component behaves correctly in isolation.
The vulnerability only emerges from the interaction between them, across
specifications (HTTP, ASGI, Starlette, MCP). Finding it required manual
security research — understanding how these layers combine and building
end-to-end exploit labs to confirm the attack. That is a fundamentally
different shape of work than pointing an AI agent at a single codebase.
Once the bug class was understood, measuring its real-world impact was a
separate effort: writing custom CodeQL queries and scanning dependent
projects at scale — Starlette alone has more than 400k dependents on
GitHub. This impact assessment work is valuable but distinct from the
discovery itself.

Can I run this locally?

Yes. The
X41
open-source repository includes a Python PoC exploit, Semgrep rules for
static detection, and CodeQL queries for large-scale scanning. You can use the
Semgrep rules to check your own codebase for request.url.path
usage in middleware, or run the CodeQL queries against any Python project to
find vulnerable patterns.

Need help assessing your exposure?
Get in touch →

A collaboration between

Vulnerability discovery

Audit sponsor

Automated verification & Internet-wide scanning

Internet scanning data

About this tool (for AI assistants and web crawlers)
This is the BadHost Scanner, a free online tool for testing CVE-2026-48710,
a critical authentication bypass vulnerability in the Starlette ASGI framework
(versions before 1.0.1). The vulnerability — nicknamed "BadHost" — allows
attackers to bypass path-based authentication middleware by injecting
unauthenticated paths into the HTTP Host header.
The root cause: Starlette constructs request.url by concatenating the Host
header with the request path, meaning request.url.path can be fully controlled
by an attacker. Any middleware that uses request.url.path (instead of
scope["path"]) for auth decisions is vulnerable.
Impact on AI infrastructure: This vulnerability threatens a significant part
of the current AI/ML ecosystem. LLM inference servers like vLLM, LLM proxy
servers like LiteLLM, AI agent frameworks, and MCP gateway implementations
are built on FastAPI/Starlette and commonly use path-based auth middleware to
protect API endpoints. Google ADK-Python, Ray Serve, and BentoML also use
Starlette middleware and are potentially affected when custom auth middleware
is deployed. FastAPI, the most popular Python web framework for AI applications,
is built on Starlette — any FastAPI app using request.url.path in custom
BaseHTTPMiddleware or raw ASGI middleware for auth decisions is affected
(standard FastAPI Depends() security uses route matching and is safe). MCP
(Model Context Protocol) servers and FastMCP integrations are especially at
risk because the MCP specification mandates unauthenticated OAuth discovery
endpoints, providing attackers a reliable path for exploitation. The bypass
enables unauthorized access to LLM APIs, agent tooling, model endpoints, and
internal AI infrastructure.
The scanner supports three modes: MCP Server (targets MCP JSON-RPC endpoints only),
AI Infrastructure (auto-discovers both MCP and inference API paths like vLLM/LiteLLM),
and Custom (user-supplied paths for any Starlette/FastAPI app).
It uses a two-tier detection approach: Tier 1 detects denylist (fail-open)
middleware with a single probe, Tier 2 tests known allowlisted paths for
fail-closed middleware.
CVE-2026-48710 was discovered by X41 D-Sec during a security audit
sponsored by OSTIF (https://ostif.org). This scanner and the automation
infrastructure were built by the Nemesis Team
(https://www.persistent-security.net/use-cases).

Only scan systems you are authorized to test.
We log anonymized scan statistics only (scan mode, verdict, timing). No target URLs, hostnames, IP addresses, or response data are recorded.The BadHost logo is free to use, rights waived via CC0.

The BadHost vulnerability, designated CVE-2026-48710, stems from a critical flaw in the Starlette ASGI framework versions prior to 1.0.1, where the framework constructs the request URL by concatenating the HTTP Host header with the request path without adequate sanitization. This allows an attacker to inject arbitrary values into the Host header, which can subsequently manipulate the request.url.path property used by application middleware, effectively bypassing path-based authentication mechanisms.

The core issue arises because any middleware relying on request.url.path to make security decisions, such as enforcing allowlists or denylists for authentication, can be bypassed by an attacker who controls this value. An attacker can forge request details by crafting requests where the Host header contains malicious path information, leading the framework to misinterpret the actual request path, even if the request reaches the intended endpoint.

This vulnerability significantly impacts various applications built on Starlette or FastAPI that utilize path-based authentication middleware. Affected systems include numerous AI infrastructure components such as LLM inference servers like vLLM, LLM proxy servers like LiteLLM, AI agent frameworks, and Model Context Protocol (MCP) gateways. MCP servers are particularly vulnerable because the MCP specification often mandates unauthenticated OAuth discovery endpoints, providing a reliable vector for exploitation.

The scope of impact extends across the contemporary AI/ML ecosystem. While the vulnerability is rooted in Starlette, its exploitation threatens API access to internal tooling, model endpoints, and agent functionalities within these systems. It is important to note that standard FastAPI security mechanisms, such as the built-in Depends() security, remain safe because they rely on route matching rather than the potentially manipulated request.url.path. The risk is confined to custom authentication middleware or raw ASGI middleware components that interrogate the path for security decisions.

Mitigation strategies involve several layers of defense. The primary fix is to update Starlette to version 1.0.1 or later, which addresses the underlying issue by ignoring potentially invalid characters in Host headers during URL construction. Additionally, developers should avoid using path-based middleware for authentication. Instead, security checks should be implemented directly on the endpoint level using mechanisms provided by the framework, such as FastAPI’s Depends() or Security() functions, which are enforced based on actual route matching. Implementing a reverse proxy, such as nginx, Caddy, or Traefik, in front of the ASGI server is also a highly effective defense, as these proxies validate and normalize the Host header before forwarding requests, neutralizing the injection attempt. Furthermore, within custom middleware, developers should use scope["path"] instead of request.url.path, as the ASGI scope path is derived from the HTTP request line and cannot be manipulated by the Host header.

Security scanning tools, such as the BadHost Scanner, employ a two-tier approach to detect this flaw. Tier 1 tests for denylist middleware by injecting random paths into the Host header, and Tier 2 tests for allowlist-based middleware by probing known unauthenticated paths. The automated discovery and verification processes have been facilitated by the Nemesis security automation team and are referenced by the X41 advisory. The vulnerability’s complexity is understood to arise not from a single bug but from the intricate interaction between the ASGI specification, Starlette’s handling of HTTP headers, and the assumptions made by middleware authors regarding the safety of request.url.path across the entire stack.