CVE-2026-100394

Nezha Monitoring is a self-hostable, lightweight, servers and websites monitoring and O&M tool. From 2.2.7 until 2.2.11, ServiceSentinel.worker in service/singleton/servicesentinel.go checked an owned service under servicesLock and later dereferenced pointer-valued serviceStatusToday and serviceCurrentStatusData entries under serviceResponseDataStoreLock without revalidating that ServiceSentinel.Delete had not removed them. A RoleMember could concurrently report TCP or ICMP results through the member's own agent and delete the same owned service, causing a nil pointer dereference. Because the gRPC server had no recovery interceptor, the worker panic terminated the whole dashboard process and disrupted every tenant's web interface, REST API, and agent connections. The issue affects availability only and does not disclose or modify data. This issue is fixed in versions 2.2.11 and 2.3.0.

Nezha Monitoring is a self-hostable, lightweight, servers and websites monitoring and O&M tool. From 2.2.7 until 2.2.11, ServiceSentinel.worker in service/singleton/servicesentinel.go checked an owned service under servicesLock and later dereferenced pointer-valued serviceStatusToday and serviceCurrentStatusData entries under serviceResponseDataStoreLock without revalidating that ServiceSentinel.Delete had not removed them. A RoleMember could concurrently report TCP or ICMP results through the member's own agent and delete the same owned service, causing a nil pointer dereference. Because the gRPC server had no recovery interceptor, the worker panic terminated the whole dashboard process and disrupted every tenant's web interface, REST API, and agent connections. The issue affects availability only and does not disclose or modify data. This issue is fixed in versions 2.2.11 and 2.3.0.

Summary

A single low-privilege RoleMember can take the entire Nezha dashboard offline, and with it every tenant's web UI, REST API, and agent connections, by racing two ordinary operations on their own service. The crash is a nil pointer dereference in the service-monitor worker at service/singleton/servicesentinel.go:601. The worker checks a service exists under one lock and later writes to two pointer-valued status maps under a different lock; a concurrent delete removes the entries in the gap. Because the gRPC server has no recovery interceptor, the worker-goroutine panic kills the whole process. Availability only: nothing is read or modified.

Affected versions

Confirmed in v2.2.7 through v2.2.10. service/singleton/servicesentinel.go has the same vulnerable implementation in all four releases. The issue is fixed in v2.2.11 and later; users should upgrade to the latest release, v2.3.0.

The bug

The worker validates an incoming report and later writes it to two status maps, but the check and the write are guarded by two different locks taken at two different times. Between them, the same member can delete the service and pull the map entries out from under the worker.

The maps hold pointers, so a missing key returns nil and the first field write through it panics:

73:  serviceStatusToday       map[uint64]*_TodayStatsOfService
74:  serviceCurrentStatusData map[uint64]*serviceTaskStatus

The worker checks presence via Get, which takes servicesLock and releases it. canReportServiceResult rejects a nil service here, so at this point the service is known to exist:

532:  cs, _ := ss.Get(r.Data.GetId())          // servicesLock.RLock / RUnlock
535:  if !canReportServiceResult(cs, reporter, r.Data.GetType()) { continue }

For TCP/ICMP ping results, every AvgPingCount (default 2, TSDB off) the worker does a synchronous DB.Create at :569 holding neither status-map lock, which stretches the gap into an easily raceable window. It then takes a different lock and dereferences the maps with no recheck and no lazy create:

597:  ss.serviceResponseDataStoreLock.Lock()
600:  ss.serviceStatusToday[mh.GetId()].Delay = ...   // nil deref if deleted meanwhile
609:  ss.serviceCurrentStatusData[mh.GetId()].t ...   // same hazard

Meanwhile Delete removes both entries under serviceResponseDataStoreLock, running on the HTTP-handler goroutine, a different goroutine from the single worker:

378:  func (ss *ServiceSentinel) Delete(ids []uint64) {
387:      delete(ss.serviceCurrentStatusData, id)
390:      delete(ss.serviceStatusToday, id)

The precise point: the check reads the services map under servicesLock; the write touches serviceStatusToday under serviceResponseDataStoreLock. Holding the second lock at :600 proves nothing about whether the entry survived, because the delete ran under that same lock while the worker was still busy between the two operations. This is a cross-lock TOCTOU, not a data race. Every access to the two maps is correctly synchronized under one lock, so -race reports nothing; the staleness lives across the two locks, not inside one memory location.

Two supporting facts. The ping map a few lines up self-heals on a miss (:543), so it never faces this; the two status maps never do. And the gRPC server is built with only real-IP and WAF interceptors (cmd/dashboard/rpc/rpc.go:37), no recovery, so the worker panic is fatal to the whole process rather than a dropped request.

Reachability

Both legs are things a member is meant to do with their own resources: report ping results over gRPC with their own agent secret, and create/delete their own service over POST /api/v1/service and POST /api/v1/batch-delete/service, which pass CheckPermission for an owned service. No admin rights, no other tenant involved. batchDeleteService reaches ServiceSentinel.Delete synchronously on a separate goroutine from the worker, so the two…

Nezha Monitoring is a self-hostable, lightweight, servers and websites monitoring and O&M tool. From 2.2.7 until 2.2.11, ServiceSentinel.worker in service/singleton/servicesentinel.go checked an owned service under servicesLock and later dereferenced pointer-valued serviceStatusToday and serviceCurrentStatusData entries under serviceResponseDataStoreLock without revalidating that ServiceSentinel.Delete had not removed them. A RoleMember could concurrently report TCP or ICMP results through the member's own agent and delete the same owned service, causing a nil pointer dereference. Because the gRPC server had no recovery interceptor, the worker panic terminated the whole dashboard process and disrupted every tenant's web interface, REST API, and agent connections. The issue affects availability only and does not disclose or modify data. This issue is fixed in versions 2.2.11 and 2.3.0.

Nezha Monitoring is a self-hostable, lightweight, servers and websites monitoring and O&M tool. From 2.2.7 until 2.2.11, ServiceSentinel.worker in service/singleton/servicesentinel.go checked an owned service under servicesLock and later dereferenced pointer-valued serviceStatusToday and serviceCurrentStatusData entries under serviceResponseDataStoreLock without revalidating that ServiceSentinel.Delete had not removed them. A RoleMember could concurrently report TCP or ICMP results through the member's own agent and delete the same owned service, causing a nil pointer dereference. Because the gRPC server had no recovery interceptor, the worker panic terminated the whole dashboard process and disrupted every tenant's web interface, REST API, and agent connections. The issue affects availability only and does not disclose or modify data. This issue is fixed in versions 2.2.11 and 2.3.0.

Summary

A single low-privilege RoleMember can take the entire Nezha dashboard offline, and with it every tenant's web UI, REST API, and agent connections, by racing two ordinary operations on their own service. The crash is a nil pointer dereference in the service-monitor worker at service/singleton/servicesentinel.go:601. The worker checks a service exists under one lock and later writes to two pointer-valued status maps under a different lock; a concurrent delete removes the entries in the gap. Because the gRPC server has no recovery interceptor, the worker-goroutine panic kills the whole process. Availability only: nothing is read or modified.

Affected versions

Confirmed in v2.2.7 through v2.2.10. service/singleton/servicesentinel.go has the same vulnerable implementation in all four releases. The issue is fixed in v2.2.11 and later; users should upgrade to the latest release, v2.3.0.

The bug

The worker validates an incoming report and later writes it to two status maps, but the check and the write are guarded by two different locks taken at two different times. Between them, the same member can delete the service and pull the map entries out from under the worker.

The maps hold pointers, so a missing key returns nil and the first field write through it panics:

73:  serviceStatusToday       map[uint64]*_TodayStatsOfService
74:  serviceCurrentStatusData map[uint64]*serviceTaskStatus

The worker checks presence via Get, which takes servicesLock and releases it. canReportServiceResult rejects a nil service here, so at this point the service is known to exist:

532:  cs, _ := ss.Get(r.Data.GetId())          // servicesLock.RLock / RUnlock
535:  if !canReportServiceResult(cs, reporter, r.Data.GetType()) { continue }

For TCP/ICMP ping results, every AvgPingCount (default 2, TSDB off) the worker does a synchronous DB.Create at :569 holding neither status-map lock, which stretches the gap into an easily raceable window. It then takes a different lock and dereferences the maps with no recheck and no lazy create:

597:  ss.serviceResponseDataStoreLock.Lock()
600:  ss.serviceStatusToday[mh.GetId()].Delay = ...   // nil deref if deleted meanwhile
609:  ss.serviceCurrentStatusData[mh.GetId()].t ...   // same hazard

Meanwhile Delete removes both entries under serviceResponseDataStoreLock, running on the HTTP-handler goroutine, a different goroutine from the single worker:

378:  func (ss *ServiceSentinel) Delete(ids []uint64) {
387:      delete(ss.serviceCurrentStatusData, id)
390:      delete(ss.serviceStatusToday, id)

The precise point: the check reads the services map under servicesLock; the write touches serviceStatusToday under serviceResponseDataStoreLock. Holding the second lock at :600 proves nothing about whether the entry survived, because the delete ran under that same lock while the worker was still busy between the two operations. This is a cross-lock TOCTOU, not a data race. Every access to the two maps is correctly synchronized under one lock, so -race reports nothing; the staleness lives across the two locks, not inside one memory location.

Two supporting facts. The ping map a few lines up self-heals on a miss (:543), so it never faces this; the two status maps never do. And the gRPC server is built with only real-IP and WAF interceptors (cmd/dashboard/rpc/rpc.go:37), no recovery, so the worker panic is fatal to the whole process rather than a dropped request.

Reachability

Both legs are things a member is meant to do with their own resources: report ping results over gRPC with their own agent secret, and create/delete their own service over POST /api/v1/service and POST /api/v1/batch-delete/service, which pass CheckPermission for an owned service. No admin rights, no other tenant involved. batchDeleteService reaches ServiceSentinel.Delete synchronously on a separate goroutine from the worker, so the two…

Nezha Monitoring: Whole-instance DoS in Nezha dashboard: a member can crash the process for every tenant in github.com/nezhahq/nezha