Nezha dashboard can be crashed by any low-privilege member

A security advisory published on 15 October 2026 warns that a single low-privilege member can crash the entire Nezha Monitoring dashboard, taking every tenant's web interface, REST API and agent connections offline. The flaw, tracked as CVE-2026-100394, is rated as an availability-only issue, meaning nothing is read or changed, according to the advisory.

The advisory explains that the crash is a nil pointer dereference in the service-monitor worker. A low-privilege member can trigger it by racing two ordinary operations on their own service: reporting a monitoring result and deleting the service. When the two interleave, the worker tries to write to internal status maps for a service that has just been removed, and the resulting panic kills the whole process.

According to the advisory, the problem is a cross-lock time-of-check to time-of-use flaw, not a simple data race. The worker checks that the service exists under one lock, then later writes to two pointer-valued status maps under a different lock. In the gap between the two, the same member can delete the service and remove the map entries. Because the maps hold pointers, a missing key returns nil and the first write through it crashes the program. The advisory notes that standard race detection tools report nothing, because every individual map access is correctly synchronised; the staleness lives across the two separate locks.

The advisory says the window is widened for TCP and ICMP ping results. Every few reports the worker performs a synchronous database write while holding neither status-map lock, which stretches the gap into what the advisory calls an easily raceable window. It then takes the second lock and dereferences the maps with no recheck. A supporting detail cited in the advisory is that the gRPC server is built with only real-IP and web application firewall interceptors and no recovery interceptor, so a worker panic is fatal to the whole process rather than a dropped request.

Both actions are things a member is meant to do with their own resources, the advisory says. A member can report ping results over gRPC using their own agent secret, and can create or delete their own service through the REST API, which passes the permission check for an owned service. No admin rights are needed, and no other tenant is involved. The advisory states that the delete runs synchronously on a separate goroutine from the single worker, so the two operations can interleave freely.

The advisory confirms the bug is present in versions v2.2.7 through v2.2.10, which all share the same vulnerable implementation. It has been fixed in v2.2.11 and later. Users are advised to upgrade to the latest release, v2.3.0.

To demonstrate the issue, the advisory includes a proof of concept that runs against a real running build of the dashboard using the project's own generated proto client and a plain HTTP client. The advisory says the test driver uses only the member's own credentials, targets only the member's own service, and is strictly for local authorised testing. The dashboard was built with SQLite, the default average ping count of two, and time-series storage disabled, both of which are described as defaults.