# Host header routing and vhost confusion

Unvalidated Host header selects vhost, default route, or redirect target instead of being rejected

_Area: Web infrastructure and server-side requests. Seen in 3 disclosed reports; one confirmed bounty: $10,000; latest 2021-02-11. Updated 2026-10-24._

## How it works
Servers assume the Host header names a site they actually serve. When that assumption breaks, the request is routed to a default vhost, an internal app, or echoed into a redirect. The attacker controls which site the frontend thinks is being requested, so the frontend serves or redirects to something it should not.

## Where it shows up
- A configured default vhost that proxies, hosts user content, or redirects to HTTP, reached when Host is unrecognized [E1](https://bugbountylibrary.com/r/h1%3A501.md)
- Shared TLS certificates covering many domains, where co-tenants can be impersonated via the default route [E1](https://bugbountylibrary.com/r/h1%3A501.md)
- Shared frontends (e.g. App Engine) routing by Host to internal-only hostnames [E2](https://bugbountylibrary.com/r/blog%3Aezequiel-tech-p-10k-host-header-html.md)
- Framework host allowlists built from config strings into regexes, especially leading-dot host patterns [E3](https://bugbountylibrary.com/r/h1%3A1047447.md)
- Host value used verbatim in a Location header or redirect [E3](https://bugbountylibrary.com/r/h1%3A1047447.md)

## How to review
Check the invariant: every request's Host must match an explicitly served name, and anything else must be rejected before routing or redirecting. Concretely:
- Send Host values for names in the certificate but not served locally; confirm rejection, not default-vhost handling [E1](https://bugbountylibrary.com/r/h1%3A501.md)
- Enumerate internal hostnames and replay them against the public frontend; confirm each enforces its own auth [E2](https://bugbountylibrary.com/r/blog%3Aezequiel-tech-p-10k-host-header-html.md)
- For allowlist regexes, test whether the prefix group can be satisfied by attacker syntax like `#`, `@`, or userinfo delimiters [E3](https://bugbountylibrary.com/r/h1%3A1047447.md)
- Confirm redirects use a validated host, never the raw header.

## Variants seen
- Default vhost fallback on shared-cert servers enabling impersonation of co-tenants [E1](https://bugbountylibrary.com/r/h1%3A501.md)
- Host-based routing to internal apps that skip the SSO/account check others enforce [E2](https://bugbountylibrary.com/r/blog%3Aezequiel-tech-p-10k-host-header-html.md)
- Over-permissive leading-dot regex in HostAuthorization allowing off-site redirect [E3](https://bugbountylibrary.com/r/h1%3A1047447.md)

## Why fixes fail
E3 shows a sanitizer that looks anchored but wraps the host in `(\A(.+\.)?<host>\z)`, so any prefix ending in the domain passes; the check exists but does not constrain the value. E2 shows per-app auth checks applied inconsistently, so routing alone reached an app missing the check.

## Impact and severity
Led to impersonation of domains sharing a certificate [E1](https://bugbountylibrary.com/r/h1%3A501.md), exposure of a confidential internal site [E2](https://bugbountylibrary.com/r/blog%3Aezequiel-tech-p-10k-host-header-html.md), and off-site redirect/phishing [E3](https://bugbountylibrary.com/r/h1%3A1047447.md). Severity rises with shared frontends, internal-only hostnames reachable from outside, and missing per-app auth.

## Evidence
- E1: https://bugbountylibrary.com/r/h1%3A501.md
- E2: https://bugbountylibrary.com/r/blog%3Aezequiel-tech-p-10k-host-header-html.md
- E3: https://bugbountylibrary.com/r/h1%3A1047447.md