Loading vulnerability…
CVE-2026-48710, also known as BadHost, affects Starlette versions prior to 1.0.1. The vulnerability is caused by Starlette reconstructing request.url from unvalidated user-controlled HTTP Host header data. In the vulnerable logic in starlette/datastructures.py, Starlette combines the ASGI scheme, the raw Host header, and the raw request path into a URL string and parses it. Because the router continues to use the raw ASGI scope path while request.url is rebuilt from the Host header, a malformed Host value containing URL delimiters such as '/', '?', or '#' can cause request.url.path to differ from the actual requested path. This parser differential creates a dual-interpretation condition where middleware or endpoints that make security decisions based on request.url or request.url.path can be misled into treating a protected request as if it targeted an allowlisted or benign path, while the underlying route still executes the original protected path.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
1 valid exploit after Mallory filtered fakes, detection scripts, and README-only repos (2 hidden).
This repository is a self-contained training lab and proof-of-concept for a Starlette Host-header URL confusion vulnerability identified as X41-2026-002 / GHSA-86qp-5c8j-p5mr. It is not a weaponized exploit kit; it is a minimal reproducible lab showing how an attacker can bypass path-based authorization when application logic trusts request.url.path, while Starlette routing still uses the raw ASGI scope['path']. Repository structure: app/vulnerable_app.py contains the intentionally vulnerable Starlette application; fixed/fixed_app.py contains a mitigated version for side-by-side comparison; exploit/exploit.sh is the main PoC script; docker-compose.yml and Dockerfile build and expose both services; requirements.txt pins Starlette 0.37.2 and uvicorn 0.29.0; README.md explains the bug, exploitation flow, and mitigations. Main exploit capability: the exploit sends a normal GET request to /admin but injects URL metacharacters into the Host header, especially 'foo?' or 'foo#'. In the vulnerable app, AuthMiddleware.dispatch reads request.url.path into reconstructed_path and allows requests when that path is '/' or ''. Because request.url is reconstructed from the untrusted Host header, a request like GET /admin with Host: foo? yields a reconstructed URL similar to 'http://foo?/admin', making request.url.path parse as empty. The middleware therefore allows the request, but routing still dispatches to the /admin handler using request.scope['path']='/admin'. This results in an authorization bypass and disclosure of the demo secret FLAG{host_header_url_confusion}. Exploit behavior: exploit/exploit.sh defaults to localhost:8000, first verifies that /admin normally returns 403, then retries with crafted Host headers. It demonstrates successful bypass payloads ('Host: foo?' and 'Host: foo#') and a non-working example ('Host: foo/x'). The vulnerable admin handler returns JSON exposing the secret plus diagnostic fields: scope_path, reconstructed_url, reconstructed_path, and host_header, making the discrepancy explicit. Fixed behavior: fixed/fixed_app.py mitigates the issue in two ways: it bases authorization on request.scope['path'] instead of request.url.path, and it adds TrustedHostMiddleware with allowed hosts localhost, 127.0.0.1, and localhost:8001. As a result, malformed Host headers are rejected before application logic, and even without that middleware the auth decision would no longer be confused by URL reconstruction. Overall assessment: this is a legitimate web exploit PoC/lab for an auth bypass caused by Host-header-driven interpretation conflict. It is concise, reproducible, and intended for local training. The exploit is proof-of-concept maturity rather than operational malware: it demonstrates the vulnerability and leaks a demo flag, but does not provide persistence, code execution, or post-exploitation features.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
107 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.
A Host header validation flaw in the Starlette library, referred to as BadHost, that can be chained with CVE-2026-42271 to bypass authentication and achieve unauthenticated remote code execution.
An authentication bypass vulnerability in LiteLLM/its Starlette framework handling that allows forged host headers to bypass credential requirements, enabling chaining with CVE-2026-42271 for unauthenticated remote code execution.
A Starlette Host Header validation bypass that enables authentication bypass; when chained with CVE-2026-42271 it allows unauthenticated remote code execution against LiteLLM deployments.
A host header validation bypass vulnerability in Starlette that can bypass LiteLLM authentication in affected deployments; when chained with CVE-2026-42271 it enables unauthenticated remote code execution.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.