GHSA-9rc6-8cjv-rcvx: Nezha Monitoring: OAuth2 Redirect URL — Host Header Injection
1. DescriptionThe `getRedirectURL` function in `oauth2.go:22-29` constructs the OAuth2 callback URL by concatenating the request's `Host` header with a fixed path, with **zero validation** of the Host header:**File:** `cmd/dashboard/controller/oauth2.go:22-29`This function is called from `oauth2redirect()` at line 53:The `redirectURL` is passed into `o2confRaw.Setup(redirectURL)` which configures the OAuth2 `Config.RedirectURL` field (`oauth2config.go:22-33`). This `RedirectURL` is sent to the OAuth2 provider (e.g., GitHub, Google, Microsoft) as the callback endpoint. The OAuth2 provider will redirect the user's browser — along with the authorization code — to this URL after the user authenticates.The security issue is that `c.Request.Host` is directly user-controllable via the HTTP `Host` header. An attacker who can control which Host header reaches the oauth2redirect handler can:Set `Host: evil.com``getRedirectURL` returns `https://evil.com/api/v1/oauth2/callback`The OAuth2 provider redirects the victim's auth code to `evil.com`The attacker's server at `evil.com` captures the auth codeThe attacker exchanges the code for an access token, binding the victim's OAuth identity to the attacker's dashboard accountThe scheme detection (lines 24-27) uses `X-Forwarded-Proto` and the `Referer` header, both of which are also user-controllable in certain configurations, so the attacker can force `https://` scheme in the redirect URL.The `oauth2callback` handler at line 129 later uses `state.RedirectURL` (which is stored in `singleton.Cache` at line 65) when calling `exchangeOpenId` at line 152. The cached `redirectURL` was set during the initial `oauth2redirect` call, tying the attack flow together.2. PoCA conceptual attack (no Docker needed):**Prerequisites for full exploit:**The victim must click the attacker's crafted linkThe OAuth2 provider must accept the attacker's domain as a valid redirect URI (some providers accept `https://*/*` or allow wildcards; others are strict)3. Impact**Account takeover**: an attacker who intercepts the OAuth2 authorization code can bind the victim's OAuth identity (GitHub, Google, GitLab, etc.) to their own dashboard account, gaining the victim's access level and permissions**Privilege escalation**: if the victim is an admin, the attacker gains full administrative control over the Nezha deployment — access to all servers, credentials, and configuration**Persistence**: once bound, the attacker retains access even if the victim resets their password (unless they also unbind the OAuth2 identity)The attack complexity is higher than typical Host header injection scenarios because it requires:The `Host` header to reach the dashboard's handler unmodified (bypassing reverse proxy normalization)The OAuth2 provider to have loose redirect URL validationUser interaction (the victim must authenticate)However, the code-level vulnerability is unambiguous: the application trusts attacker-controlled input (`Host` header) for a security-critical URL that participates in the OAuth2 authorization code flow.4. Remediation**Validate the Host header** against a configured allowlist of known dashboard hostnames:**Pin the redirect URL** to the configured dashboard URL from `singleton.Conf` instead of deriving it from the request Host header:**Remove Host header-based URL construction** entirely — the OAuth2 redirect URL should be deterministic based on server configuration, not dynamic per-request**Add Host header validation middleware** for all OAuth2-related endpoints as defense-in-depth
CVSS v3.1: 6.8