A lock‑order inversion between UpdateGroup and DeleteGroup triggers a deadlock when authenticated non‑admin users concurrently call the notification‑group and batch‑delete endpoints with oversized id lists. The race condition can be widened to close an ABBA cycle, permanently blocking the alerting subsystem until a restart. The result is that alert delivery ceases, effectively denying service to monitoring stakeholders.

Nezha versions from 1.8.0 up to 2.3.12 are affected. The vulnerability is present in the nezhahq:nezha product, and any deployment that enables authenticated non‑admin access to the notification‑group or batch‑delete endpoints is at risk.

The CVSS score of 6 indicates moderate severity. EPSS data is unavailable and the vulnerability is not listed in the CISA KEV catalog, so current exploitation likelihood is uncertain. Attacks require authenticated non‑admin access, limiting the threat to insiders or compromised accounts. Despite this, the ability to lock out alert delivery is a significant operational risk. The exploit path involves exploiting a concurrency invariant by sending large id lists to the two endpoints simultaneously, which is straightforward with valid credentials.