CVE-2026-101090 in Nezha
Summary
by MITRE • 09/28/2026
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} (cmd/dashboard/controller/oauth2.go) 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, 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 (dashboard_host empty). At the time of the advisory no patched version was available.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/28/2026
The vulnerability identified in Nezha versions prior to 2.2.3 represents a critical regression in the OAuth2 authentication flow, specifically within the dashboard's handling of host headers during identity provider redirections. This flaw stems from an improper validation and fallback mechanism when the optional configuration parameter dashboard_host is left empty or unset. In such configurations, the application fails to default securely to the install_host setting as intended by previous security patches. Instead, it directly reflects the value of the HTTP Host header provided in the incoming request into the redirect_uri parameter sent to the external OAuth2 identity provider. This behavior creates a significant divergence between the expected secure configuration and the actual runtime behavior, allowing an attacker to manipulate the destination where authentication credentials are delivered.
From a technical perspective, this vulnerability exploits the trust relationship inherent in OAuth2 flows by manipulating the state of the redirect_uri parameter. When a user initiates login through Nezha, the application constructs a URL pointing to the identity provider that includes a callback address. Under normal circumstances with proper configuration, this address points back to the legitimate Nezha instance. However, due to the regression described in GHSA-9rc6-8cjv-rcvx not being fully effective when dashboard_host is empty, an attacker can craft a request containing a forged Host header that matches their own malicious server domain. The application accepts this host value and embeds it into the redirect_uri. Consequently, upon successful authentication at the identity provider, the authorization code or token is redirected to the attacker-controlled endpoint rather than back to Nezha.
The operational impact of this vulnerability is severe, leading directly to account takeover scenarios. By intercepting the authorization code via the forged callback URL, an attacker can complete the OAuth2 binding flow on behalf of the victim. This allows the adversary to link their own credentials with the victim's existing Nezha dashboard account or create a new administrative session using the stolen tokens. Since this process occurs without the victim's knowledge and bypasses standard password-based authentication checks for that specific login instance, it constitutes a complete compromise of user identity within the management interface. This is particularly dangerous in environments where Nezha serves as a central monitoring hub, potentially granting attackers access to sensitive infrastructure metrics and control capabilities.
This flaw aligns with CWE-20 Improper Input Validation, specifically regarding the failure to validate that input parameters conform to expected safe defaults when optional configuration fields are absent. It also maps closely to ATT&CK technique T1566.001 Spearphishing Link, as it requires an initial interaction where a victim is induced to make a request with a manipulated Host header, often facilitated through social engineering or malicious links that force specific HTTP headers in certain proxy or client configurations. The regression nature of this bug highlights the importance of rigorous testing for configuration-dependent security controls, ensuring that fallback mechanisms are robust and do not revert to insecure defaults based on external input.
Mitigation strategies must focus on both immediate remediation and long-term architectural improvements. Administrators should immediately ensure that the dashboard_host setting is explicitly configured in their Nezha installation files rather than left empty, forcing the application to use a known safe value instead of reflecting user-supplied headers. For those unable to modify configuration files directly due to deployment constraints, deploying a reverse proxy such as Nginx or Apache can be effective; these proxies should be configured to strip or override incoming Host headers with the correct internal hostname before forwarding requests to Nezha. This ensures that even if an attacker attempts header injection at the network level, the application receives only trusted host values.
Furthermore, developers and maintainers must address this regression by implementing strict validation logic for all redirect URIs involved in OAuth2 flows. The system should enforce a whitelist of allowed domains or strictly validate that the generated redirect_uri matches the configured base URL regardless of incoming headers. Implementing state parameters with cryptographic binding can also mitigate some risks associated with open redirects, although it does not fully resolve the issue if the initial URI construction is flawed. Regular security audits and regression testing are essential to prevent similar vulnerabilities from re-emerging in future updates, ensuring that configuration defaults remain secure by design rather than relying on external input for critical routing decisions.