CVE-2026-53523: Nezha Monitoring OAuth2 Host Header Injection Vulnerability

Technical summary

The vulnerability exists in the getRedirectURL function within oauth2.go (lines 22-29) of Nezha Monitoring. The function constructs OAuth2 callback URLs by directly concatenating the HTTP request's Host header with a fixed path segment, without any validation, allowlisting, or sanitization of the Host header value. This allows an attacker to inject arbitrary host values into the callback URL, which is then used by the OAuth2 provider to validate the redirect destination. An attacker who controls or can influence the Host header (e.g., via DNS poisoning, ARP spoofing, or misconfigured reverse proxies) can redirect the authentication callback to a malicious server, capturing OAuth2 tokens or session cookies. CWE-601 (URL Redirection to Untrusted Site / Open Redirect) is the root cause classification.

Business impact

Exploitation could allow attackers to intercept OAuth2 authentication tokens and session credentials from legitimate users. In deployments where Nezha Monitoring is used to manage critical infrastructure or sensitive environments, token theft could lead to unauthorized access to the monitoring platform and, by extension, the monitored systems. This is particularly concerning for organizations relying on Nezha for observability of production environments. The attack requires user interaction (a user must initiate OAuth2 login) but leverages a widely-available attack vector (Host header injection).

Affected systems

Nezha Monitoring versions 1.0.0 through 2.1.x are vulnerable. Version 2.2.0 and later contain the patch. Self-hosted deployments are directly affected; as no vendor product information was provided in the source data, you should verify whether any third-party distributions or integrations of Nezha Monitoring exist in your environment.

Exploitability

Exploitation requires network-level access to inject or manipulate the Host header during an OAuth2 authentication attempt, along with user interaction (the user must initiate login). The CVSS 3.1 score of 6.8 (MEDIUM, AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N) reflects that while the confidentiality and integrity impacts are high (token theft, session hijacking), the attack complexity is high and requires user interaction. The vulnerability is not currently tracked in the CISA KEV catalog, indicating no active, widespread exploitation has been reported as of the publication date.

Remediation

Upgrade Nezha Monitoring to version 2.2.0 or later. The patch implements proper validation and sanitization of the Host header before using it to construct OAuth2 callback URLs. Organizations should prioritize this upgrade for instances exposed to untrusted networks or handling sensitive monitoring of critical systems. After patching, verify that OAuth2 authentication flow works correctly in your environment.

Patch guidance

Apply the upgrade to Nezha Monitoring version 2.2.0 or any subsequent version. Before deploying in production, test OAuth2 authentication workflows (login, callback, token validation) to ensure the patch does not introduce regressions. Verify the patch against the official Nezha Monitoring release notes and repository to confirm the getRedirectURL function has been updated with Host header validation. If you are running a version between 1.0.0 and 2.1.x, treat the upgrade as a security priority.

Detection guidance

Monitor HTTP request logs for unusual or unexpected Host header values being sent to your Nezha Monitoring instance, particularly those containing external domain names or IP addresses not matching your legitimate deployment. Check for OAuth2 callback URLs with unexpected hostnames in application logs or browser network traces during authentication flows. Organizations with network-level visibility can detect Host header injection attempts by correlating Host headers with the actual SNI (Server Name Indication) in TLS handshakes or with the destination IP of the request; mismatches may indicate an injection attempt. Enable and review OAuth2 provider logs for unexpected redirect_uri parameters.

Why prioritize this

Upgrade to version 2.2.0 should be prioritized for any Nezha Monitoring instance that supports OAuth2 authentication, particularly if it is exposed to untrusted networks or accessed by users outside a secured perimeter. The MEDIUM severity combined with the requirement for user interaction means this is not a critical drop-everything issue, but the potential for token theft in monitoring platforms—which are often trust anchors for infrastructure—makes it a near-term remediation candidate. Prioritize instances managing production infrastructure above lab or development instances.

Risk score, explained

The CVSS 3.1 MEDIUM score (6.8) reflects a high-impact vulnerability (confidentiality and integrity both rated High due to potential token theft) with moderate attack friction (high attack complexity, user interaction required). The score appropriately captures that while successful exploitation leads to serious consequences, the attacker must overcome multiple practical obstacles: network positioning to inject the Host header, user action to initiate OAuth2 login, and typically some social engineering or environmental control. Organizations with strict network segmentation or single-sign-on environments may face lower practical risk than those with internet-facing Nezha deployments.

Frequently asked questions