Nezha Dashboard CVE-2026-101086

Requires an authenticated Nezha Dashboard account (before v2.3.5) holding the nezha:service:write scope; no user interaction and no admin rights are needed. Exploitation is bounded by the attacker's existing authorization scope - privileged Command/ApplyConfig/Exec tasks can only be delivered to Agents the attacker is already authorized over, so a single-user or tightly-scoped deployment sharply limits blast radius, while a multi-tenant instance that hands service:write to low-trust users is fully exposed. The limiting factor is the pre-existing authenticated, scoped account; the enabling condition is the unvalidated Task.Type accepted by the service API sharing the protobuf integer namespace with privileged operations.

This is a genuine privilege-escalation issue (CWE-269) rather than a high-CVSS-but-hollow finding, but its real-world urgency is moderate and gated by authentication. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N, score 7.1) confirms network reachability, low complexity, and NO required user interaction, but PR:L means the attacker must already hold an authenticated account carrying the nezha:service:write scope - this is not an unauthenticated internet-facing bug. The vendor scored only VC:H with VI:N/VA:N, which UNDERSTATES the impact: the flaw lets an attacker deliver command-execution and Agent-configuration tasks to Agents, which is by definition integrity- and availability-affecting (arbitrary code execution on monitored hosts), so my independent assessment raises Integrity and Availability and treats the compromised Agents as a scope change. No EPSS score, no CISA KEV listing, and no public POC were provided, so exploitation status is 'no public exploit identified at time of analysis' - this argues against imminent mass exploitation, but the root cause (a shared protobuf Task.Type integer namespace between benign service monitors and privileged Command/ApplyConfig/Exec tasks) is conceptually simple and clearly documented in the patch/tests, lowering the bar for a motivated authenticated insider. Net: a real priority for multi-tenant Nezha deployments where low-privilege users hold service:write, and a lower priority for single-operator/self-hosted single-user instances.

A low-privilege authenticated Nezha user who holds the nezha:service:write scope creates or updates a 'service monitor' via the service API but sets its Task.Type to a privileged value (Command, ApplyConfig, or Exec) instead of a supported probe type such as TCPPing. The dashboard dispatches the crafted task to Agents within the user's authorization scope, executing arbitrary commands or pushing malicious Agent configuration. No public exploit code was identified at time of analysis, though the fix commit ships security tests that concretely demonstrate the rejected task-type values.