CVE-2026-101090: Nezha through 2.2.3 Host Header Injection via OAuth2 redirect_uri
Nezha 2.2.3 contains a Host header injection regression in the OAuth2 redirect endpoint. When the new optional dashboardhost setting is empty, /api/v1/oauth2/{provider} (cmd/dashboard/controller/oauth2.go) reflects the attacker-supplied HTTP Host header into the redirecturi sent to the identity provider instead of falling back to the configured installhost. An attacker who induces a victim to begin OAuth2 login via a request that reaches Nezha with a forged Host header can cause an attacker-controlled callback URL to be used as the redirecturi; if the OAuth2 provider accepts it, the victim's authorization code is delivered to the attacker origin, allowing the attacker to complete the OAuth2 login/binding flow and take over the account. This regresses the fix for GHSA-9rc6-8cjv-rcvx and is configuration-dependent (dashboardhost empty). At the time of the advisory no patched version was available.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Set the optional dashboard_host setting to the trusted configured dashboard hostname instead of leaving it empty, so OAuth2 redirect_uri construction does not use the attacker-supplied Host header.
Nezha dashboard dashboard_host = configured trusted dashboard hostname
Event History
Frequently Asked Questions
Which deployments are affected by this issue?
The issue is configuration-dependent: it affects Nezha deployments where the optional dashboard_host setting is empty. In that state, the OAuth2 redirect endpoint uses the incoming HTTP Host header rather than the configured install_host.
What must an attacker do to exploit it?
An attacker must induce a victim to start an OAuth2 login through a request that reaches Nezha with a forged Host header. Exploitation also depends on the OAuth2 provider accepting the attacker-controlled callback URL supplied as redirect_uri.
What is the impact if exploitation succeeds?
The victim's OAuth2 authorization code can be sent to an attacker-controlled origin. The attacker can then complete the OAuth2 login or binding flow and take over the victim's account.
What can be done while no patch is available?
Configure dashboard_host rather than leaving it empty, so the OAuth2 redirect endpoint does not reflect the request Host header. No patched version was available at the time of the advisory.