CVE-2026-101086 in nezha
Summary
by MITRE • 09/28/2026
Nezha Dashboard versions before 2.3.5 fail to restrict service monitor task types to supported probe types, allowing authenticated users with nezha:service:write scope to submit privileged task types through the service API. Attackers can deliver command execution or Agent configuration tasks to Agents within their authorization scope by exploiting the shared protobuf Task.Type namespace between service monitors and privileged operations.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/28/2026
The vulnerability in Nezha Dashboard versions prior to 2.3.5 represents a critical access control failure rooted in improper validation of input parameters during task submission via the service API. Specifically, the application fails to restrict the types of tasks that can be initiated through its monitoring endpoints, allowing authenticated users possessing only the nezha:service:write scope to submit privileged task types intended for administrative or high-privilege operations. This flaw arises from a shared protobuf Task.Type namespace used by both standard service monitors and sensitive operational commands, which lacks sufficient separation or validation logic at the API level. Consequently, an attacker with legitimate but limited credentials can bypass expected restrictions and execute actions that should be reserved for higher-level administrators.
From a technical perspective, this issue is classified under CWE-269 Improper Privilege Management because it allows a user to perform functions requiring higher privileges than those granted by their assigned role. The core mechanism of exploitation involves manipulating the Task.Type field within API requests sent to the Nezha service monitor endpoint. Since the system does not validate whether the requested task type is appropriate for the current authorization level, the backend processes these requests as if they originated from an administrative context. This leads directly to CWE-798 Use of Hard-coded Credentials or Privilege Context Confusion depending on how the internal agent interprets the command, but primarily it reflects a failure in enforcing least privilege principles during runtime operation execution.
The operational impact of this vulnerability is severe, as it enables remote code execution and unauthorized configuration changes across managed agents within the attacker’s authorization scope. By submitting crafted task payloads through the service API, an adversary can deliver arbitrary commands to connected Nezha Agents or modify their configurations without detection by standard security controls that rely on role-based access restrictions. This effectively escalates a low-privilege account into one capable of compromising host systems, exfiltrating data, establishing persistence mechanisms, or disrupting critical monitoring infrastructure. The ability to alter agent configuration further exacerbates the risk by allowing attackers to disable logging, evade detection tools, or create backdoors for future exploitation attempts.
This vulnerability aligns with MITRE ATT&CK technique T1059 Command and Scripting Interpreter, as it facilitates direct command execution on remote systems through legitimate administrative channels. Additionally, it relates to T1484 Domain Policy Modification if the exploited configuration changes affect security policies or group policy objects managed by the agents. The exploitation path also mirrors aspects of T1078 Valid Accounts since attackers leverage existing authenticated sessions rather than breaking into new accounts, making detection more challenging for traditional signature-based systems that do not monitor API parameter anomalies closely enough to identify privilege escalation attempts via task type manipulation.
Mitigation strategies must focus on immediate patching and enhanced input validation. Organizations running Nezha Dashboard versions before 2.3.5 should upgrade to the latest stable release where this access control flaw has been addressed by implementing strict type checking for all API-submitted tasks. Administrators should also enforce principle of least privilege across all user roles, ensuring that service monitor permissions do not inadvertently grant capabilities associated with administrative functions. Implementing additional logging and monitoring around task submission endpoints can help detect anomalous behavior indicative of exploitation attempts. Furthermore, network segmentation limiting access to the Nezha API from untrusted zones adds another layer of defense against potential abuse by compromised low-privilege accounts or external attackers who have gained initial foothold through other vectors.