Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-09-27T21:17:03.003Z",
  "pubdate": "2026-09-27T21:17:03.003Z",
  "executiveSummary": "Nezha version 2.2.3 is affected by a critical Host header injection vulnerability within its OAuth2 authentication flow, specifically located in the redirect endpoint.\nThe vulnerability allows an unauthenticated remote attacker to manipulate the 'redirect_uri' parameter sent to identity providers by injecting a malicious Host header.\nThis flaw occurs when the 'dashboard_host' configuration is left empty, causing the application to improperly rely on the incoming request's Host header instead of a secure fallback mechanism.\nSuccessful exploitation enables an attacker to intercept the victim's authorization code by redirecting the OAuth2 callback to an attacker-controlled origin.\nThis effectively grants the attacker the ability to hijack user sessions or bind unauthorized identities to victim accounts, bypassing standard authentication security controls.\nThe issue is characterized as a regression of a previous security fix (GHSA-9rc6-8cjv-rcvx), necessitating immediate configuration hardening or application-level patching to mitigate the risk of account takeover.",
  "technicalDetails": "The vulnerability resides in the OAuth2 implementation within 'cmd/dashboard/controller/oauth2.go'. The endpoint '/api/v1/oauth2/{provider}' is responsible for initiating the handshake with external identity providers.\nThe root cause is a failure to properly sanitize the host context when constructing the OAuth2 authorization request. When the optional configuration parameter 'dashboard_host' is undefined or empty, the application logic defaults to extracting the domain from the incoming HTTP Host header provided by the client request.\nAn attacker can exploit this by crafting an HTTP request with a spoofed 'Host' header pointing to a malicious server under their control. When the victim initiates the OAuth2 login flow, the application reflects this forged Host header into the 'redirect_uri' parameter transmitted to the OAuth2 provider.\nIf the identity provider fails to strictly validate the redirect_uri against an allowlist, it will redirect the victim's browser to the attacker-supplied URL after successful authentication, appending the victim's sensitive OAuth2 authorization code as a query parameter.\nThe attacker then captures this authorization code from their server's logs and proceeds to complete the OAuth2 exchange, successfully impersonating the victim or binding the attacker's credentials to the victim's account within Nezha.\nThe attack flow follows these steps: 1. The attacker identifies the target Nezha instance with an empty 'dashboard_host' configuration. 2. The attacker triggers a victim to initiate a login via a malicious request containing a manipulated Host header. 3. Nezha generates a redirect URL to the identity provider that includes the attacker-controlled origin in the 'redirect_uri'. 4. The victim authenticates with the identity provider. 5. The identity provider redirects the victim to the attacker's server with the authorization code. 6. The attacker uses the captured code to gain unauthorized access to the victim's account.\nThis vulnerability is particularly dangerous as it regresses a previous fix and exploits a common trust-misconfiguration in how web applications handle host-derived URLs for critical security callbacks. No authentication is required for an attacker to initiate this request, and it is accessible over the public network."
}