CVE-2026-101090: Nezha OAuth2 Auth Bypass Vulnerability

CVE-2026-101090 Overview

CVE-2026-101090 is a Host header injection vulnerability in Nezha 2.2.3, a server and service monitoring platform. The flaw resides in the OAuth2 redirect endpoint /api/v1/oauth2/{provider} implemented in cmd/dashboard/controller/oauth2.go. When the optional dashboard_host setting is empty, the endpoint reflects the attacker-supplied HTTP Host header into the redirect_uri parameter sent to the identity provider instead of using the configured install_host. An attacker who tricks a victim into initiating OAuth2 login through a forged Host header can hijack the authorization code and take over the account. The issue regresses the prior fix tracked as GHSA-9rc6-8cjv-rcvx.

Critical Impact
Successful exploitation allows account takeover via OAuth2 authorization code theft when dashboard_host is unset.

Affected Products

Nezha dashboard versions through 2.2.3
Deployments where the dashboard_host configuration setting is empty
Instances exposing /api/v1/oauth2/{provider} to untrusted networks

Discovery Timeline

2026-09-27 - CVE-2026-101090 published to NVD
2026-09-28 - Last updated in NVD database

Technical Details for CVE-2026-101090

Vulnerability Analysis

The vulnerability is classified under [CWE-601] URL Redirection to Untrusted Site (Open Redirect). It affects the OAuth2 login initiation flow inside the Nezha dashboard controller. The handler constructs the redirect_uri parameter sent to the upstream OAuth2 identity provider using the inbound HTTP Host header. Because the Host header is attacker-controllable through proxying, DNS manipulation, or forged requests, the resulting redirect_uri can point to any origin. When the identity provider accepts the manipulated callback, it issues the authorization code to the attacker-controlled host instead of the legitimate dashboard. The attacker then completes the OAuth2 exchange and binds or authenticates as the victim.

Root Cause

The handler in oauth2.go previously fell back to a server-side install_host value whenever the deployment did not supply an explicit host. The 2.2.3 release introduced an optional dashboard_host setting but failed to preserve that fallback when the new setting is empty. Instead, the code trusts r.Host from the inbound request. This regresses the earlier fix for GHSA-9rc6-8cjv-rcvx and reintroduces attacker influence over the OAuth2 redirect target.

Attack Vector

Exploitation requires no authentication and no user interaction beyond the victim starting the OAuth2 login flow. An attacker crafts a link that routes the victim's browser through infrastructure that rewrites or forges the Host header reaching the Nezha dashboard. The dashboard emits an authorization URL containing an attacker-chosen redirect_uri. If the configured OAuth2 provider does not strictly validate the redirect URI against a registered allowlist, the issued authorization code is delivered to the attacker, enabling full account compromise.

At the time of the advisory no patched version was available, and exploitation depends on the deployment leaving dashboard_host empty. See the GitHub Security Advisory and the VulnCheck Advisory on Host Header Injection for additional technical detail.

Detection Methods for CVE-2026-101090

Indicators of Compromise

Requests to /api/v1/oauth2/{provider} where the inbound Host header does not match the dashboard's canonical hostname.
OAuth2 provider logs showing redirect_uri values pointing to unexpected domains for the Nezha client application.
Successful account bindings or logins from IP addresses or user agents inconsistent with the account owner's baseline.
Multiple authorization code exchanges correlated with mismatched Host headers observed in dashboard access logs.

Detection Strategies

Inspect reverse proxy and web server logs for Nezha requests containing Host header values outside the approved hostname set.
Alert on any outbound OAuth2 authorization URL whose redirect_uri parameter does not resolve to the canonical dashboard URL.
Correlate successful OAuth2 callbacks with the originating Host header seen during the authorization request.

Monitoring Recommendations

Enable verbose logging on the Nezha dashboard and the fronting proxy to capture full request headers for OAuth2 endpoints.
Monitor identity provider audit logs for authorization code issuance anomalies involving the Nezha client.
Track configuration drift on the dashboard_host setting to detect deployments that revert to the vulnerable empty state.

How to Mitigate CVE-2026-101090

Immediate Actions Required

Set dashboard_host to the canonical public hostname of the Nezha dashboard to force the safe fallback path.
Configure the upstream OAuth2 provider to enforce a strict allowlist of permitted redirect_uri values.
Restrict the fronting reverse proxy to accept only requests whose Host header matches the expected dashboard hostname.
Rotate OAuth2 client secrets and invalidate active sessions if logs show evidence of header manipulation.

Patch Information

At the time of the advisory, the maintainers had not released a patched version of Nezha. Monitor the GitHub Security Advisory for release updates and apply the fixed version as soon as it becomes available.

Workarounds

Populate the dashboard_host configuration key with the dashboard's trusted hostname.
Terminate TLS at a reverse proxy such as nginx or Caddy configured to reject or rewrite unexpected Host headers before forwarding to Nezha.
Disable OAuth2 login providers until the configuration or patch is in place if the dashboard is exposed to the public internet.

bash

# nginx example: enforce canonical Host header for Nezha dashboard
server {
    listen 443 ssl;
    server_name dashboard.example.com;

    if ($host != "dashboard.example.com") {
        return 400;
    }

    location / {
        proxy_set_header Host dashboard.example.com;
        proxy_pass http://127.0.0.1:8008;
    }
}