CVE-2026-105112 in Nezha
Summary
by MITRE • 10/03/2026
Nezha from 1.8.0 before 2.3.13 contains a lock-order inversion in UpdateGroup and DeleteGroup that allows authenticated non-admin users to deadlock the alerting subsystem. Attackers can concurrently call the notification-group and batch-delete endpoints with oversized id lists to widen the race and close an ABBA cycle, permanently killing alert delivery until restart.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/03/2026
The vulnerability identified in Nezha versions prior to 2.3.13 represents a critical concurrency flaw rooted in lock-order inversion within the application's group management subsystem. This issue specifically affects authenticated non-administrative users who possess permissions to interact with notification groups and perform batch deletions. The core technical defect lies in the inconsistent acquisition of mutex locks during the execution of UpdateGroup and DeleteGroup operations. In concurrent programming, when multiple threads or processes attempt to acquire two or more locks simultaneously but do so in a different order depending on their specific code path, a deadlock condition known as an ABBA cycle can occur. Here, one thread may hold lock A while waiting for lock B, while another thread holds lock B and waits for lock A, resulting in both threads being permanently blocked.
The operational impact of this vulnerability is severe due to its effect on the alerting subsystem's availability. By exploiting this race condition through concurrent API calls, an attacker can reliably trigger a deadlock that halts all alert delivery mechanisms within the system. The use of oversized identifier lists during batch-delete operations serves to widen the window for the race condition, making it easier to achieve the necessary synchronization conflict. Once the deadlock is established, the alerting subsystem becomes unresponsive until the entire application process is restarted by an administrator. This effectively creates a denial-of-service scenario where critical monitoring and notification capabilities are suspended, potentially leading to missed security incidents or system failures that require immediate attention but go undetected due to the broken alert pipeline.
From a classification perspective, this vulnerability aligns with CWE-836, which describes the use of multiple locks in an inconsistent order, often referred to as lock-order inversion. It also relates to CWE-401 regarding missing or improper synchronization mechanisms that allow race conditions to occur. In terms of offensive security frameworks such as MITRE ATT&CK, this behavior can be categorized under Tactic TA0005 Defense Evasion and specifically Technique T1562 Impair Defenses, as the attacker is actively disabling a defensive monitoring capability through resource exhaustion via logical deadlock rather than traditional system crashes. The exploitation requires authentication, which limits the attack surface to compromised or malicious insider accounts but significantly increases the severity due to the persistent nature of the impact until manual intervention occurs.
Mitigation strategies must focus on both immediate remediation and long-term architectural improvements. The primary solution is to upgrade Nezha to version 2.3.13 or later, where this lock-order inversion has been resolved by enforcing a consistent global ordering for all mutex acquisitions related to group operations. For environments unable to patch immediately, administrators should implement strict rate limiting on the notification-group and batch-delete endpoints to reduce the probability of concurrent execution overlapping in a way that triggers the deadlock. Additionally, introducing timeout mechanisms for database or internal lock acquisition can prevent threads from waiting indefinitely, allowing the system to recover gracefully rather than entering a permanent deadlocked state. Code reviews focusing on concurrency patterns should also be conducted to ensure no other similar inversion vulnerabilities exist within the application's resource management logic.