CVE-2026-100394 in Nezha
Summary
by MITRE • 10/15/2026
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.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/15/2026
The vulnerability identified in Nezha Monitoring represents a critical concurrency flaw within the ServiceSentinel worker component, specifically located in the service/singleton/servicesentinel.go module. This self-hosted monitoring tool is designed to track server health and website availability for multiple tenants through a centralized dashboard. The core issue stems from improper synchronization of shared data structures during concurrent operations. Specifically, while the code correctly acquires servicesLock when checking an owned service, it subsequently dereferences pointer-valued entries such as serviceStatusToday and serviceCurrentStatusData under the separate serviceResponseDataStoreLock without revalidating that these pointers remain valid. This gap in logic creates a race condition where the state of the data can change between the initial check and the subsequent access attempt.
The operational impact is severe due to the lack of error handling mechanisms within the gRPC server architecture. When a RoleMember agent concurrently reports TCP or ICMP results while simultaneously deleting its associated service, the worker process attempts to dereference memory addresses that have already been freed by the deletion routine. This action triggers a nil pointer dereference panic in Go. Because the gRPC server implementation lacks a recovery interceptor to catch and handle such panics gracefully, the entire dashboard process terminates abruptly. Consequently, this results in a complete denial of service for all tenants connected to the system, disrupting access to the web interface, REST API endpoints, and agent connections simultaneously.
From a security classification perspective, this vulnerability is primarily categorized under CWE-476: NULL Pointer Dereference, which describes the act of using a pointer that references memory not allocated or already freed by the program. In terms of attack vectors and tactical behavior, this aligns with ATT&CK technique T1529: System Shutdown/Reboot, as the exploitation leads to an immediate cessation of system services. Although the vulnerability does not allow for data disclosure or modification, its impact on availability is significant, effectively rendering the monitoring infrastructure unusable until manual intervention restarts the service.
Mitigation strategies focus primarily on upgrading to patched versions where this concurrency issue has been resolved. Administrators should immediately update Nezha Monitoring to version 2.2.11 or later, including version 2.3.0 and beyond, which implement proper synchronization checks before dereferencing shared pointers. For environments that cannot be updated immediately, implementing a recovery interceptor in the gRPC server configuration can provide temporary resilience by catching panics and restarting worker goroutines rather than terminating the entire process. Additionally, enforcing strict access controls to limit RoleMember privileges may reduce the likelihood of concurrent delete operations triggering this race condition during normal operational workflows.