Nezha EUVD-2026-92016

Requires a valid authenticated non-admin account on the Nezha instance (CVSS PR:L). The attacker must concurrently call the notification-group UpdateGroup/DeleteGroup path and the batch-delete endpoint, supplying oversized id lists to widen the race window and close an ABBA lock-order-inversion cycle (CVSS AC:H plus AT:P reflect the timing/race dependency). Only Nezha versions 1.8.0 up to but not including 2.3.13 are affected. Limiting factors: exploitation is probabilistic (depends on winning a concurrency race), needs authentication, and yields only a denial of the alerting subsystem recoverable by restart - no code execution, data access, or integrity impact.

This is a moderate-severity availability-only flaw, not a top-tier priority. The CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:L/UI:N) and the 6.0 base score are internally consistent with the description: network-reachable, but gated by authentication (PR:L - an authenticated non-admin account) and by winning a timing-dependent ABBA race (AC:H plus AT:P, present attack requirement). Impact is strictly availability (VC:N/VI:N/VA:H) - the alerting subsystem deadlocks and stays dead until restart; there is no confidentiality or integrity impact. No EPSS score, CISA KEV entry, POC, or SSVC decision point was supplied, so exploitation is 'no public exploit identified at time of analysis.' Conflict to flag explicitly: the input Tags include 'Information Disclosure,' which contradicts both the description (a deadlock/denial-of-service) and the CVSS impact metrics (VC:N, confidentiality = none) - the tag is mislabeled and should be treated as a race-condition DoS. The practical risk is bounded by the need for valid credentials and by the probabilistic race window, making targeted abuse by an authenticated tenant the realistic threat rather than mass unauthenticated exploitation.

An authenticated non-admin user of a shared Nezha instance repeatedly and concurrently invokes the notification-group update/delete endpoints and the batch-delete endpoint, passing oversized id lists to widen the race window. When the ABBA lock-order inversion closes, the alerting subsystem deadlocks, and monitoring alerts stop being delivered until an operator restarts the service. No public exploit code was identified; exploitation requires winning a timing-sensitive race (CVSS AC:H/AT:P), so reliability is probabilistic.