CVE-2026-101090: Nezha Regression Lets Attackers Hijack OAuth2 Logins via Host Header

Overview

Nezha is an open-source server monitoring and management dashboard. CVE-2026-101090 is a textbook case of a security fix regressing: Nezha had already patched a Host header injection flaw affecting its OAuth2 login flow (tracked as GHSA-9rc6-8cjv-rcvx), but version 2.2.3 reintroduces the same weakness for a specific, easy-to-hit configuration state — when the newly added optional dashboard_host setting is left empty.

In that state, Nezha's /api/v1/oauth2/{provider} endpoint once again reflects the attacker-supplied HTTP Host header into the redirect_uri it sends to the configured OAuth2 identity provider (GitHub, and any other configured provider), even when a separate install_host value is properly configured. The regression is rated CVSS 9.3–9.8 (Critical) depending on scoring source and tracked as GHSA-rf68-8gjr-36q7, disclosed around September 15, 2026 with the CVE published September 27, 2026.

Technical Details

Exploitation status: Not currently listed as known-exploited; the advisory frames this as a configuration-dependent regression rather than a universally exploitable default, but the triggering condition (dashboard_host unset) is a realistic state for any deployment that hasn't explicitly populated the newly introduced field.

How It Works

Nezha's original fix for the Host header injection issue (GHSA-9rc6-8cjv-rcvx) made the OAuth2 redirect logic fall back to a trusted, administrator-configured value — install_host — instead of trusting the client-supplied Host header when building the redirect_uri sent to an identity provider during login.

Version 2.2.3 introduced a new, optional setting, dashboard_host, presumably to give operators finer control over the dashboard's externally visible hostname in more complex deployments (behind multiple proxies, custom domains, etc.). The regression is in how the fallback chain was rewritten: the current logic only falls back to install_host when dashboard_host is non-empty — inverting the safety property the original fix relied on. When dashboard_host is left at its default empty value (which it will be for any operator who never knew the setting existed), Nezha's /api/v1/oauth2/{provider} handler goes right back to reflecting the raw Host header from the incoming request into the redirect_uri field of the outbound OAuth2 authorization request — regardless of whether install_host is correctly set.

A concrete attack request illustrates the mechanics:

GET /api/v1/oauth2/github?type=1 HTTP/1.1
Host: evil.attacker.test
X-Forwarded-Proto: https

If this request reaches Nezha with the forged Host header intact (a plausible outcome depending on how any front-end proxy or load balancer is configured), Nezha constructs and sends a redirect_uri pointing at evil.attacker.test rather than the legitimate dashboard host. If the configured OAuth2 provider (e.g., GitHub) accepts that redirect URI for the registered application — which many OAuth2 apps do when redirect URI validation is loose or wildcard-based — the identity provider will deliver the victim's authorization code to the attacker's domain once the victim completes login. The attacker can then exchange that code to complete the OAuth2 binding or login flow as the victim.

Impact Assessment

Who Is At Risk

Any Nezha deployment through version 2.2.3 that has not explicitly set the dashboard_host configuration value — which describes most upgraded instances, since it is a new, optional field that existing operators would have no reason to know to populate. Risk is further gated by whether the front-end network path (reverse proxy, load balancer, CDN) preserves or forwards a client-controlled Host header to Nezha unmodified.

Potential Attack Chains

1. Phishing-assisted redirect — Attacker crafts a link to the victim's legitimate Nezha instance's OAuth2 login endpoint, but the request is routed (or the attacker controls a proxy/DNS layer) such that the Host header seen by Nezha is attacker-controlled.
2. Authorization code interception — The identity provider (e.g., GitHub) sends the OAuth2 authorization code to the attacker-controlled redirect_uri instead of the legitimate Nezha dashboard.
3. Session/account takeover — The attacker exchanges the intercepted authorization code to complete the login or account-binding flow, gaining access to the victim's Nezha session or linked identity.

Practical Caveat

Exploitation depends on the OAuth2 provider accepting the attacker-supplied redirect URI as valid for the registered application, and on the network path actually delivering a forged Host header to Nezha rather than a proxy normalizing or overwriting it. Both conditions vary by deployment, which is why this is scored as network-critical but not universally guaranteed to succeed against every instance.

Mitigation

Immediate Actions

• Explicitly set dashboard_host to your legitimate, externally-visible dashboard hostname, even though it's documented as optional — this is the only currently available way to restore the safe fallback behavior, since no code fix has been released as of publication.
• Verify your OAuth2 application's registered redirect URI(s) with each provider are set to exact-match, not wildcard or prefix-match, so that even a manipulated Host header can't produce a redirect_uri the provider will accept.
• Ensure any reverse proxy or load balancer in front of Nezha overwrites or strictly validates the Host header rather than passing through whatever the client sent, and strip or normalize X-Forwarded-Host/X-Forwarded-Proto unless explicitly required.

Detection Opportunities

• Monitor OAuth2 provider application logs (e.g., GitHub OAuth app authorization logs) for authorization requests carrying redirect_uri values that don't match your known, legitimate dashboard hostname.
• Review web server / reverse proxy access logs for requests to /api/v1/oauth2/{provider} carrying unexpected or unfamiliar Host header values.
• Watch for unusual login or account-binding activity immediately following any detected anomalous OAuth2 redirect attempt.

Defence-in-Depth

• Treat every optional "hostname override" configuration field introduced in an update as security-relevant until proven otherwise — this regression exists specifically because a new optional field changed a fallback chain's default-safe behavior.
• When a vendor patches a Host header injection or open-redirect issue, re-verify the fix after any subsequent update that touches related configuration, rather than assuming a prior fix remains intact indefinitely.
• Given no vendor fix is currently available, track the GHSA-rf68-8gjr-36q7 advisory and the Nezha project's release notes for a forthcoming patch, and apply it as soon as it ships.

Background

CVE-2026-101090 is notable less for novel technique and more for what it represents: a regression of a previously fixed vulnerability, triggered by a subsequent feature addition (dashboard_host) that didn't account for the safety property the original fix depended on. This is a recurring failure pattern in software security — a fix that works correctly for the configuration state it was tested against can silently stop working once a later change alters that state's assumptions. Projects and operators alike should treat any change to authentication- or redirect-related configuration surfaces as requiring a fresh look at previously closed security advisories in the same code path, not just a check against the current change's own test suite.

As of publication, no patched version has been released, making the configuration-level mitigation (setting dashboard_host explicitly) the only available defense for affected Nezha operators.

References

• NVD — CVE-2026-101090
• GitHub Security Advisory — GHSA-rf68-8gjr-36q7
• Prior advisory — GHSA-9rc6-8cjv-rcvx