Nezha's authenticated agents can forge service-monitor results for other users' services
Date: 2026-06
Affected: go/github.com/nezhahq/nezha, go/github.com/nezhahq/nezha
Attack vector: auth-bypass
Category: vulnerability-disclosure
Severity: High
CVE: CVE-2026-48119
CWE: CWE-862
CVSS: 7.1 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L)

#### Summary Nezha accepts service-monitor `TaskResult` messages from an authenticated agent based only on whether the reported service ID exists. The dashboard authenticates the agent and derives the reporter server ID from the gRPC stream, but the service-monitor result worker does not verify that the reporter server was selected for that service, belongs to the service owner, or was actually assigned that monitoring task. A low-privilege user with a valid agent secret and one registered agent can therefore submit forged monitoring results for another user's service ID. This allows cross-tenant corruption of service-monitor history/current state, and can influence victim-owned service notifications with attacker-controlled result text. #### Details The agent task stream accepts inbound `TaskResult` messages after authenticating agent metadata: - `service/rpc/auth.go:23-60` validates `client_secret` and `client_uuid`. - `service/rpc/auth.go:63-75` registers an unknown valid UUID as a server for the authenticated secret owner. - `service/rpc/nezha.go:40-48` authenticates the `RequestTask` stream and binds it to `clientID`. - `service/rpc/nezha.go:50-56` receives agent-controlled `TaskResult` messages. - `proto/nezha.proto:60-65` defines attacker-controlled `TaskResult.id`, `type`, `delay`, `data`, and `successful`. For service-monitor task types, the result is dispatched directly to the service sentinel using the authenticated server ID as reporter: - `service/rpc/nezh


Mitigations:

Architectural layers (MAESTRO):