Nezha EUVD-2026-88023

Requires an authenticated account with the member role that OWNS at least one monitored agent/server (PR:L) - not achievable by unauthenticated or non-owning users. Exploitation depends on winning a narrow TOCTOU race: the attacker must issue a concurrent server-delete via POST /api/v1/batch-delete/server for their own server exactly during the sentinel worker's processing window (hence AC:H/AT:P), which may require repeated attempts. Affected only in Nezha versions >= 2.2.11 and < 2.3.1; the amplifying condition is the absence of any recover()/gRPC recovery interceptor, which turns a localized nil dereference into a full-instance crash. No user interaction from a victim is required.

This is a moderate-severity, availability-only denial-of-service issue. The vendor/VulnCheck CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:L/UI:N/VC:N/VI:N/VA:H, score 6.0) is internally consistent with the description: network-reachable but requiring an authenticated member-role account, a race-condition attack (AC:H) with a specific timing precondition (AT:P), and impact limited strictly to availability (VA:H; no confidentiality or integrity impact). CWE-367 (TOCTOU race) matches the described concurrent-delete window. No EPSS score, no CISA KEV listing, and no public POC were provided, so there is no signal of active or automatable exploitation - this is a real but self-inflicted-scope reliability bug rather than an urgent priority. The one aggravating factor is blast radius: a single crafted delete crashes the ENTIRE instance because there is no recover()/recovery interceptor, so a low-privileged tenant can take down monitoring for all users. Overall this is a legitimate hardening priority for multi-tenant Nezha operators but not a widespread-exploitation emergency; the high attack complexity (winning a concurrency race) further limits reliability of exploitation.

An authenticated user with the member role who owns at least one monitored agent issues a POST /api/v1/batch-delete/server for their own server precisely while a service sentinel worker is processing that server, winning the race window. The worker then dereferences a now-missing entry in the server-list snapshot using a stale reporter pointer, and because no recover() or gRPC recovery interceptor exists, the unrecovered panic crashes the whole Nezha instance and downs monitoring for every tenant. No public exploit code was identified at time of analysis, and the race (AC:H) may require multiple attempts to trigger.