CVE-2026-101088: Nezha before 2.3.1 Denial of Service via Concurrent Server Delete
Nezha is a server and website monitoring tool. In versions >= 2.2.11 and < 2.3.1, the service sentinel worker (service/singleton/servicesentinel.go) contains an incomplete fix for a previously reported nil dereference denial of service (GHSA-qjpp-gffx-2wm9). The 2026-07-21 fix re-validated the service lifecycle under serviceResponseDataStoreLock but reused an already-captured, now stale reporter pointer and never re-validated the server, and that lock does not guard ServerShared. An authenticated user with the member role who owns an agent can issue a concurrent server delete (POST /api/v1/batch-delete/server) for their own server to win the race window, causing the worker to dereference a missing entry in the server list snapshot. Because the sentinel workers and the gRPC server have no recover()/recovery interceptor, the resulting panic is unrecovered and crashes the entire instance. This is fixed in version 2.3.1.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Nezhato a version that resolves this vulnerability.Fixed in 2.3.1
Event History
Frequently Asked Questions
Who can exploit this issue?
An authenticated user with the member role can exploit it, but only if they own an agent and can delete their own server through the batch-delete server endpoint.
Are default deployments exposed?
The issue affects Nezha versions 2.2.11 through versions before 2.3.1. Exploitation requires a member account with ownership of an agent, rather than unauthenticated network access alone.
What is the operational impact of successful exploitation?
Winning the race causes an unrecovered panic in a sentinel worker. Because the sentinel workers and gRPC server lack recovery handling, the panic crashes the entire Nezha instance.
What should be done if upgrading cannot happen immediately?
The provided information identifies the vulnerable action as concurrent deletion of a member-owned server via POST /api/v1/batch-delete/server. Restricting or suspending member accounts that own agents, or otherwise preventing access to that deletion operation, can reduce exposure until version 2.3.1 is deployed.