Loading vulnerability…
CVE-2026-48710, known as BadHost, affects Starlette versions prior to 1.0.1. Starlette reconstructed request.url by concatenating the scheme, attacker-controlled HTTP Host header, and raw ASGI request path before parsing the resulting URL. Because Host values were not validated, URI delimiters in the header could cause the parsed request.url.path to differ from the original scope["path"] used by Starlette routing. An application could therefore route a request to a protected endpoint while path-based middleware or endpoint authorization using request.url.path interprets it as an allowed path. Version 1.0.1 validates Host header syntax during URL construction and falls back to the ASGI server address for malformed Host values.
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 (4 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.
139 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.
Referenced vulnerability; no technical details are provided.
A Starlette host-header vulnerability that can be chained with LiteLLM CVE-2026-42271 to enable unauthenticated command execution against an exposed LiteLLM gateway.
A Host Header Injection / inconsistent URL-path interpretation vulnerability in Starlette prior to 1.0.1. Malformed Host values can make authorization middleware evaluate a benign path while the Starlette router processes a protected path, enabling authorization bypass; attacker-controlled request URLs may also create SSRF risk in vulnerable application logic.
An HTTP request/response smuggling vulnerability in the Starlette lightweight ASGI framework that has been exploited in the wild.
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.