Advisory · CVE-2026-101090
Nezha OAuth2 login leaks authorization codes through a forged Host header
Nezha 2.2.3 reflects an attacker-supplied Host header into the OAuth2 redirect_uri when dashboard_host is empty, letting an attacker capture authorization codes and take over accounts.
- Vendor
- nezhahq
- Product
- Nezha
- Identifier / CWE
- CVE-2026-101090
CWE-601 - Action timing
- Immediate
Explain it like I’m five
Nezha asks the visitor's browser where to deliver a secret letter, but trusts whatever address the attacker whispers instead of its own address book. The letter, a login code, goes straight to the attacker, who uses it to walk in as the victim.
- 01Empty dashboard_host
The dashboard_host setting is optional; when left empty, Nezha 2.2.3 should fall back to the configured install_host.
- 02Host reflected
Instead, /api/v1/oauth2/{provider} reflects the attacker-supplied HTTP Host header into the redirect_uri sent to the identity provider.
- 03Code misdelivered
If the OAuth2 provider accepts the attacker-controlled callback URL, the victim's authorization code is delivered to the attacker origin.
- 04Account takeover
The attacker completes the OAuth2 login and binding flow with the stolen code, taking over the victim's account.
What happened
Nezha 2.2.3 contains a Host header injection regression in the OAuth2 redirect endpoint. When the new optional dashboard_host setting is empty, /api/v1/oauth2/{provider} reflects the attacker-supplied HTTP Host header into the redirect_uri sent to the identity provider instead of falling back to the configured install_host. 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 redirect_uri; if the OAuth2 provider accepts it, the victim’s authorization code is delivered to the attacker origin, letting the attacker complete the OAuth2 login and binding flow and take over the account.
This regresses the fix for GHSA-9rc6-8cjv-rcvx and is configuration-dependent: only deployments with dashboard_host empty are affected. At the time of the advisory, no patched version was available.
What to do
- Explicitly set dashboard_host in the Nezha configuration rather than leaving it empty, so no request Host header is trusted for redirects.
- Review the OAuth2 provider application settings and restrict registered callback URLs to the exact dashboard origin.
- Check login and binding logs for OAuth2 flows with unexpected Host headers or redirect targets.
- Force re-authentication and session rotation for accounts with suspicious OAuth2 activity.
Management note
A regressed fix is worse than a new bug: teams that believed this was already handled may not be looking. The mitigation here is configuration, not a patch, so it can be applied immediately, but it has to be applied everywhere the setting was left at its default.