Critical RCE in Nezha Monitoring Allows Cross-Tenant Agent Takeover

A critical remote code execution vulnerability has been discovered in the Nezha Monitoring dashboard. The flaw, identified as CVE-2026-46716, allows a low-privileged user to execute arbitrary shell commands on every server monitored by the platform. This vulnerability affects all versions at or before a specific master branch commit [1].

The impact is severe. An attacker with any authenticated account can achieve full system compromise across an entire fleet of monitored agents. Since Nezha agents often run with root privileges to perform system monitoring, this vulnerability effectively grants fleet-wide root access. The flaw is particularly dangerous in multi-tenant deployments or where user self-registration via OAuth2 is enabled.

The Attack Chain: From Member to Fleet-Wide Root

The attack begins with an attacker obtaining credentials for a low-privileged 'RoleMember' account. This could be a legitimate account or one created through a public-facing OAuth2 integration. Once authenticated, the attacker does not need to escalate privileges within the dashboard itself. The vulnerability provides a direct path to code execution on the monitored endpoints.

First, the attacker creates a notification webhook under their own account. This webhook points to an attacker-controlled server and serves as an exfiltration channel for the command output. Next, the attacker submits a specially crafted cron job via the dashboard's API. This job contains the malicious shell command they wish to execute.

The cron job is configured to run on all servers but specifies an empty list of servers to exclude. Due to a logic flaw, this bypasses a critical permission check. The Nezha scheduler then picks up this task and broadcasts the attacker's command to every agent connected to the dashboard. Each agent executes the command and sends the output, such as system information or sensitive file contents, to the attacker's webhook [1].

A Cascade of Authorization Failures

This vulnerability is not a single mistake but a chain of three distinct authorization failures. The first issue lies in the API routing. Endpoints for creating and modifying cron jobs were incorrectly protected by a general authentication handler, not one restricted to administrators. This allowed any authenticated user, regardless of role, to access a powerful administrative function [2].

The second failure is a logic bypass in the permission validation code. When creating a cron job, a user can specify which servers it should apply to. The system is designed to check if the user has permission for those servers. However, if an attacker submitted a job intended for all servers with an empty list of exceptions, the permission check would vacuously pass, running zero iterations and returning true.

The final and most critical failure occurs in the task execution logic. The cron scheduler function, when triggered, iterates over every single server known to the dashboard. It contained no secondary check to confirm that the user who created the job was authorized to run commands on each target server. This missing check is what enables the cross-tenant and cross-user command execution, transforming a permission bug into a fleet-wide compromise.

Implications for Agentic Infrastructure

Monitoring tools like Nezha act as the nervous system for distributed infrastructure, providing visibility and control over fleets of agents. This vulnerability demonstrates how a flaw in the central controller can lead to a total collapse of security across the entire agentic system. The trust placed in the dashboard becomes a single point of failure.

The issue highlights the critical importance of defense-in-depth for agent control planes. Relying on a single API gateway authorization check is insufficient. Each step of a high-privilege workflow, from API submission to task execution, must re-validate authority. In this case, a check within the scheduler loop could have prevented the vulnerability's catastrophic fan-out.

A companion finding further underscores the fragility of the agent control channel. The communication between the dashboard and agents used plaintext gRPC by default. This meant a network attacker could intercept traffic, steal credentials, and inject commands to achieve the same RCE outcome without any dashboard authentication at all. Securing the agent control plane requires both strong authentication on the dashboard and transport-level security for the agents.