Executive brief
Nezha v2.2.3 contains a regression in OAuth2 handling where forged HTTP Host headers are reflected into OAuth2 redirect URLs when the new `dashboard_host` configuration is left empty. An attacker can trick a victim into initiating OAuth2 login via a request with a malicious Host header, causing Nezha to send the victim's authorization code to an attacker-controlled server instead of the legitimate OAuth provider, potentially leading to account takeover if the OAuth provider accepts the forged redirect URL.
Technical details
This is a Host header injection vulnerability in the OAuth2 redirect URI construction logic in `cmd/dashboard/controller/oauth2.go`. The vulnerable code chooses the request Host header directly unless `DashboardHost` is explicitly configured as non-empty; when `DashboardHost` is empty (the default for v2.2.3), the request-supplied Host header is used to build the OAuth2 callback URL, even if `InstallHost` is configured. An attacker who can reach the Nezha instance with a forged Host header (via DNS spoofing, HTTP Host header manipulation, or misconfigured proxy) can make Nezha send an attacker-controlled redirect URI to the OAuth2 provider. If the provider accepts this URI, the victim's authorization code is exfiltrated to the attacker. This regresses a v2.2.0 fix that correctly fell back to `InstallHost`. The vulnerability requires the victim to initiate OAuth2 login and the OAuth provider to accept the forged redirect URI, but affects the realistic default/upgrade scenario where `dashboard_host` is a new optional field left unset.
Affected products
- Nezha Nezha 2.2.3
Timeline
- 2026-09-15: disclosed: Advisory published to GitHub Advisory Database