Nezha Monitoring CVE-2026-100394

Requires an authenticated Nezha account with RoleMember privileges plus a member-controlled agent bound to a service the member owns (versions 2.2.7 through 2.2.10). The attacker must concurrently (1) report TCP or ICMP results through their own agent and (2) invoke Delete on that same owned service, racing ServiceSentinel.worker so the delete removes serviceStatusToday/serviceCurrentStatusData entries after the owned-service check but before the worker dereferences those pointers under serviceResponseDataStoreLock. Limiting factors: authentication as RoleMember is mandatory (no unauthenticated path), the attacker needs control of their own agent, and exploitation hinges on winning the concurrency window (retriable). Not exploitable on versions before 2.2.7 or on fixed 2.2.11 / 2.3.0, which revalidate the entries and add serialization.

This is a genuine but bounded availability risk, best treated as a medium-priority denial-of-service issue rather than a top-tier emergency. The provided CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H, base 6.5) agrees with CWE-362 (race condition) and the description: impact is A:H only, with C:N/I:N confirming no data exposure. PR:L is consistent with the description's 'RoleMember' actor, so this is an authenticated attack, not an anonymous internet one. The one signal I would contest is AC:L - exploitation depends on winning a TOCTOU window between ServiceSentinel.Delete and the worker's dereference, which is more realistically AC:H; however, because the attacker controls both racing operations (their own agent's report and the delete of their own service) and can retry freely, the window is practically reachable, so the vendor's AC:L is defensible. No EPSS score, KEV entry, or public POC is present in the input: exploitation probability is therefore unquantified (EPSS unknown), and there is no public exploit identified at time of analysis. The amplifying factor not captured by the base score is multi-tenancy - a single low-privileged member can panic the entire gRPC process and take down every tenant's dashboard, REST API, and agent connectivity, so the blast radius exceeds the attacker's own authorization scope. Net: real and worth patching promptly in multi-tenant deployments, but not evidence of active, widespread exploitation.

A low-privileged RoleMember on a shared Nezha instance points their own agent at an owned TCP/ICMP service and begins submitting monitoring results while simultaneously issuing a delete for that same service. By repeating this until the delete lands between the worker's validation and its pointer dereference, they trigger a nil pointer dereference; with no gRPC recovery interceptor, the resulting panic crashes the whole dashboard process and knocks every tenant offline. No public exploit is identified at time of analysis, though the fixing commit ships a lifecycle test that reproduces the stale-report-after-deletion condition.