Nezha Agents Can Forge Monitoring Data via Authorization Flaw

A high-severity vulnerability in the Nezha monitoring dashboard allows authenticated agents to forge service monitoring data. The flaw, tracked as CVE-2026-48119, enables a low-privileged user to submit false status reports for services they do not own. This can lead to data corruption and inaccurate service availability reporting across different tenants in a shared environment [1].

A Failure of Agentic Trust

Nezha operates on an agentic model. Software agents are installed on monitored servers to collect and report health and performance data to a central dashboard. This architecture relies on the dashboard to not only authenticate agents but also to authorize their specific actions. The system must ensure an agent only reports on tasks it has been assigned.

The vulnerability represents a critical breakdown in this trust model. An attacker with credentials for a standard user account can register their own agent. This authenticated agent can then send monitoring results for any service on the platform, including those owned by other users. The dashboard's backend incorrectly accepts these results without verifying the agent's authority over the target service.

The Attack Path Explained

Executing an attack requires a valid, but not privileged, user account on a vulnerable Nezha instance. The attacker uses their account's secret key to authenticate a new agent that they control. This provides a legitimate communication channel to the dashboard's gRPC endpoint for submitting task results.

The attacker then identifies the numerical ID of a victim's service. They craft a `TaskResult` message containing this service ID and send it from their own agent. The message can contain falsified data, such as claiming a service is down when it is up, or reporting fabricated latency metrics [2].

Because the dashboard's result processing logic fails to perform the necessary authorization check, it accepts the fraudulent report. The system logs the fake data as if it came from a legitimate, assigned monitoring agent. This poisons the historical data and current state of the victim's service.

Technical Cause: A Gap in Result Processing

The vulnerability's root cause lies in an asymmetry between outbound task dispatch and inbound result acceptance. The dashboard's logic for assigning monitoring tasks correctly ensures that only servers designated by the service owner are asked to perform checks. However, this same rigor was missing when processing the results.

The flawed code resides in the `service/singleton/servicesentinel.go` file. When a `TaskResult` arrives, the worker confirms that the service ID within the message corresponds to a real service. It does not, however, validate that the agent submitting the result was ever assigned that task or even belongs to the service owner [2].

This oversight creates a security gap. The system implicitly trusts that any authenticated agent is authorized to report on any task. A successful patch adds the missing verification steps. The corrected code ensures the reporting agent is authorized for the service before its result is accepted, mirroring the logic used for task dispatch [3].

Impact on Multi-Tenant Environments

In shared or multi-tenant deployments of Nezha, this vulnerability breaks the isolation between users. It allows one tenant to directly interfere with the operational monitoring of another. An attacker can systematically degrade the integrity of a victim's service availability data.

The most direct impact is the corruption of monitoring data. An attacker can make a healthy service appear offline, potentially triggering unnecessary on-call alerts. Conversely, they could report a failing service as healthy, preventing incident response teams from being notified of a real outage.

The vulnerability also enables an attacker to inject arbitrary text into the data field of a forged result. This text can then be included in alert notifications sent to the victim's response teams. This could be used to cause confusion, spread misinformation, or support social engineering attacks [2].

Detection and Mitigation

The definitive mitigation is to update the Nezha dashboard to a patched version. The fix was committed to the main branch and resolves the authorization flaw completely [3]. Administrators of Nezha instances should prioritize applying this update.

Before patching, defenders can hunt for evidence of exploitation. This involves reviewing service history data for anomalies. Security teams should search for any service that has monitoring history entries from a server ID not explicitly assigned to monitor it. Such a finding would be a strong indicator of compromise.

This vulnerability underscores a critical principle for agent-based architectures. Authentication is not a substitute for authorization. Verifying who an agent is must be followed by verifying what that agent is permitted to do for every single request. Assuming that an authenticated agent is always a trustworthy and authorized actor is a design flaw that creates significant risk.