Nezha Monitoring EUVD-2026-36600

The attacker must hold a valid Nezha member account with write access to at least one registered server (PR:L per CVSS vector). The deployment must be multi-tenant - at minimum one other user must later create a DDNS profile whose auto-assigned database ID matches an ID the attacker pre-stored via the PATCH endpoint. The DDNS worker service must be active and running for the cross-profile dispatch to trigger. Exploitation probability scales with DDNS profile ID predictability: if IDs are sequential auto-increments (common ORM default, not independently confirmed by the advisory), the attacker can pre-store a contiguous range of future IDs to maximize collision probability. Exploitation is limited by: (1) authenticated member account required - unauthenticated attackers cannot exploit this; (2) the collision depends on a victim independently creating a profile with a matching ID, making exploitation probabilistic unless ID generation is predictable; (3) no direct credential disclosure - the attacker triggers DNS dispatches but cannot extract the victim's DDNS provider API keys from Nezha's HTTP responses; (4) single-user instances are entirely unexposed.

The CVSS 6.4 Medium score with S:C accurately captures the cross-tenant nature of this flaw: the attacker does not gain direct access to victim credentials but causes the DDNS worker to act on the victim's behalf, constituting a meaningful authorization boundary violation. AC:L reflects that no special exploitation complexity is required beyond account registration and ID speculation. PR:L bounds the attack surface to registered Nezha member accounts, ruling out unauthenticated exploitation. No EPSS score was provided in the available intelligence, so exploitation probability cannot be quantified. This CVE is not listed in the CISA KEV catalog, and no public exploit code has been identified at time of analysis. Real-world risk is most significant in multi-tenant Nezha deployments - shared family instances, team deployments, or hosting providers - where multiple users independently create DDNS profiles. ID predictability is the key probabilistic factor: if IDs are sequential auto-increments (typical of ORM defaults), the attacker can stage a near-deterministic collision by occupying a range of future IDs. Single-user instances are not exposed. The I:L and A:L impacts are correctly modest: the attacker cannot exfiltrate victim DDNS API keys from responses, but can cause erroneous DNS record updates and disrupt the victim's intended DDNS operation.

An attacker with a Nezha member account sends a PATCH /server/{id} request for their own registered server, supplying a ddns_profiles field referencing IDs such as 150, 151, and 152 - values not yet assigned to any profile in the database. A victim user subsequently creates a DDNS profile pointing to their Cloudflare account's API token and domain; the database auto-assigns this profile ID 150. The Nezha DDNS worker next execution cycle resolves ID 150 from the attacker's server record, constructs a DNS update request using the victim's Cloudflare API credentials and zone configuration, and issues it - potentially altering or disrupting DNS records the victim controls. No public exploit code has been identified at time of analysis.