Horizon Alert
Summary of the vulnerability and why it matters
This advisory addresses a security regression in Nezha's OAuth2 redirect functionality, specifically when a particular setting is not configured. If exploited, an attacker could manipulate the redirect process during login to gain unauthorized account access. The main concern is confirming whether your deployment of Nezha is affected and to what extent.
- A login process flaw can allow account takeover.
- Understand the risk to user authentication.
- Assess Nezha's configuration for potential exposure.
Attack Path
How an attacker could exploit the issue
An attacker can exploit this vulnerability by tricking a user into initiating an OAuth2 login. This requires the vulnerable Nezha service to be configured with an empty `dashboard_host` setting. The attacker crafts a malicious request with a forged `Host` header, which the service then includes in the redirect URI sent to the identity provider. If successful, the attacker receives the user's authorization code, enabling account takeover.
- No special access needed.
- User initiates OAuth2 login.
- Account takeover and unauthorized access.
Live Threat
Current exploitation, exposure, and threat context
This vulnerability could allow an attacker to redirect users to an attacker-controlled URL during the OAuth2 login process. When the dashboard_host setting is not configured, a forged Host header can manipulate the redirect_uri. If the identity provider accepts this forged URL, an attacker could intercept the user's authorization code, enabling them to take over the user's account by completing the OAuth2 flow.
- User account takeover.
- Exploits an OAuth2 redirect flaw.
- Compromises user account access.
Operational Fix
Recommended remediation, mitigation, and detection steps
Security teams and potentially the Nezha application owners are responsible for addressing this Host header injection vulnerability. The first practical step is to identify all instances of Nezha, determine their external reachability and business criticality, and then locate the accountable system owners. Remediation planning should be based on this risk assessment, especially since a patched version is not yet available.
- Identify Nezha instances and ownership.
- Verify external reachability and criticality.
- Plan remediation based on discovered risk.
