Nezha Monitoring CVE-2026-53523

Exploitation requires three concurrent conditions: (1) The target Nezha Monitoring instance must have OAuth2 authentication configured and enabled - instances using only local/password authentication do not exercise the vulnerable getRedirectURL code path. (2) The instance must be reachable in a deployment where the HTTP Host header is not normalized or overridden by an intermediary reverse proxy before reaching Nezha - deployments behind nginx, Caddy, or similar with explicit Host header enforcement are not exploitable via this vector. (3) A legitimate user with a valid OAuth2 account (such as an administrator) must be induced to initiate an OAuth2 login flow via an attacker-crafted link, satisfying the UI:R requirement. Exploitation is limited by: the AC:H complexity of reliably delivering a Host-injected request to a victim; the prevalence of reverse proxy deployments that silently nullify the attack; and the need for targeted social engineering rather than opportunistic scanning. No special platform, OS, or network topology beyond the above is required.

The NVD CVSS 3.1 score of 6.8 with vector AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N represents a moderate-to-high real-world risk under the right deployment conditions. AC:H accurately reflects that Host header manipulation is non-trivial: many deployments of self-hosted tools sit behind reverse proxies (nginx, Caddy, Traefik) that normalize or override the Host header before it reaches the application, effectively neutralizing the attack vector - this is a meaningful risk-reduction factor for well-architected deployments. The C:H and I:H impacts are justified because a successful redirect can capture OAuth authorization codes or tokens, enabling full account takeover. No EPSS data was available in the provided intelligence, so exploitation probability cannot be quantified. The vulnerability is not in CISA KEV and no public exploit code has been reported, indicating limited adversarial interest at time of analysis. For directly-exposed Nezha instances (no reverse proxy) with OAuth2 enabled and internet-accessible administrative users, real-world risk is meaningfully high despite the moderate overall score. The UI:R requirement limits opportunistic mass exploitation but does not prevent targeted social engineering against known administrators.

An attacker targeting a Nezha instance with OAuth2 enabled and no Host-normalizing reverse proxy crafts a link to the instance's OAuth2 initiation endpoint, ensuring the HTTP Host header is set to an attacker-controlled domain. The attacker socially engineers a Nezha administrator - via email, messaging, or a watering-hole page - into clicking the link and completing the OAuth2 login flow; the OAuth authorization code or token is then delivered to the attacker's server, granting full account access. No public proof-of-concept code has been identified at time of analysis, but the attack technique is well-understood and requires no specialized tooling beyond the ability to set custom HTTP headers.