Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-09-27T21:17:02.727Z",
  "pubdate": "2026-09-27T21:17:02.727Z",
  "executiveSummary": "The vulnerability is a nil pointer dereference leading to a Denial of Service (DoS) in the Nezha server monitoring tool, specifically within the service sentinel worker component.\nThis issue stems from an incomplete resolution of a previous vulnerability (GHSA-qjpp-gffx-2wm9) where the service lifecycle validation fails to account for race conditions involving concurrent server deletions.\nAn authenticated user with a member role and ownership of an agent can trigger a service panic by winning a race condition during a batch-delete request.\nBecause the sentinel workers and the gRPC server lack proper panic recovery or middleware interceptors, a successful trigger results in an unhandled exception that causes the entire Nezha instance to crash.\nThe vulnerability affects Nezha versions 2.2.11 through 2.3.0, necessitating an immediate update to version 2.3.1 to ensure service availability and stability.",
  "technicalDetails": "The vulnerability exists in the file service/singleton/servicesentinel.go, which handles the sentinel worker logic. The root cause is a race condition arising from improper synchronization and stale object referencing. Although the 2026-07-21 fix attempted to re-validate service lifecycles under the serviceResponseDataStoreLock, it failed to address the underlying concurrency issues regarding the server state.\nThe sentinel worker captures a pointer to a reporter object and proceeds with execution without verifying if the server object remains valid in the global state. The lock mechanism employed (serviceResponseDataStoreLock) does not adequately protect the ServerShared structure. Consequently, if an attacker issues a POST /api/v1/batch-delete/server request simultaneously, the server entry is removed from the internal list while the sentinel worker is still processing the stale pointer.\nWhen the sentinel worker attempts to dereference this now-nil or missing entry, a panic is triggered. In the Nezha architecture, the sentinel workers and the primary gRPC server lack a global recover() mechanism or a recovery interceptor. This results in the propagation of the panic to the main process thread, leading to an immediate and unrecoverable crash of the entire application instance.\nTo exploit this, an authenticated attacker must have a member role with ownership of an agent. By initiating a race condition where the server is deleted while the sentinel is performing a health check or sentinel operation, the attacker can force the service to access memory that has been deallocated or cleared from the active server list. The absence of defensive null checks or proper synchronization primitives allows the attacker to predictably cause a crash, effectively denying service to all other users of the Nezha instance."
}