CVE-2026-101085 in Nezha
Summary
by MITRE • 09/28/2026
Nezha before 2.3.8 fails to validate alert rule type and duration bounds, allowing authenticated non-administrator users to create malformed rules that trigger unrecovered panics in the alert evaluator goroutine. Attackers can submit a crafted alert rule via the POST /api/v1/alert-rule endpoint to crash the dashboard process, which persists the rule and causes repeated crashes on restart, disabling all monitoring and control plane functionality.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/28/2026
The vulnerability identified in Nezha versions prior to 2.3.8 represents a critical failure in input validation within the alerting subsystem of the application. Specifically, the system fails to enforce strict bounds checking on two key parameters associated with alert rules: the rule type and the duration settings. This lack of sanitization allows authenticated non-administrator users to submit malformed data structures that do not conform to expected logical or syntactic constraints. The attack vector is accessible through the POST /api/v1/alert-rule endpoint, which accepts user-defined configurations for monitoring alerts without sufficiently validating the integrity of these inputs before processing them further into the application logic.
The technical flaw lies in the alert evaluator goroutine, which processes incoming rule definitions to determine when and how notifications should be triggered. When a malformed rule is submitted, particularly one with invalid type identifiers or out-of-bounds duration values, the internal evaluation engine encounters an unexpected state that it cannot handle gracefully. Instead of returning a validation error or rejecting the input, the application triggers an unrecovered panic within this goroutine. In Go-based applications, such panics typically result in the termination of the specific routine and can lead to broader system instability if not properly recovered by higher-level handlers. In this case, the failure propagates effectively enough to crash the dashboard process entirely.
The operational impact of this vulnerability is severe due to its persistence mechanism. The application saves the malformed rule configuration to persistent storage before or during the evaluation phase that leads to the panic. Consequently, even if the service is restarted manually by an administrator, the system will attempt to load and evaluate these invalid rules again upon boot-up. This creates a denial-of-service condition where the monitoring dashboard becomes permanently unavailable until the corrupted data is manually removed from the database or configuration files. Since Nezha serves as a central control plane for infrastructure monitoring, this outage disables all visibility into server health metrics and alerts, leaving administrators blind to potential security incidents or performance degradations across their monitored environment.
From a classification perspective, this vulnerability aligns with CWE-20 Improper Input Validation, as the application fails to verify that user-supplied input meets expected criteria before processing it. Additionally, because the attack requires authentication but does not require administrative privileges, it reflects CWE-786 Access of Static Memory outside allocated bounds or similar memory safety issues depending on the specific implementation details of the panic trigger. In terms of adversary tactics, this aligns with MITRE ATT&CK technique T1499 Endpoint Denial of Service, where an attacker aims to disrupt availability by exhausting resources or crashing services rather than stealing data or gaining persistent access for lateral movement.
Mitigation strategies must focus on immediate remediation and future prevention. The primary solution is to upgrade Nezha to version 2.3.8 or later, where the input validation logic has been corrected to properly reject malformed rule types and duration bounds before they reach the evaluator goroutine. For environments that cannot immediately patch due to operational constraints, administrators should audit their alert rule configurations for any entries with unusual type codes or extreme duration values. Removing these specific records from the persistent storage will restore service availability after a restart until the software update can be applied. Future development practices should enforce strict schema validation at the API layer and implement panic recovery mechanisms in critical goroutines to ensure that individual evaluation failures do not compromise the entire dashboard process.