Nezha — CraftedSignal Threat Feed

Nezha Monitoring Cross-Tenant RCE via Cron Task Injection

hello@craftedsignal.io — Sat, 23 May 2026 00:19:38 +0000

The Nezha monitoring dashboard is vulnerable to a cross-tenant RCE. A RoleMember (Role==1), even one self-registered via OAuth2, can exploit insufficient authorization checks in the cron task creation process (POST /api/v1/cron and PATCH /api/v1/cron/:id). The vulnerability stems from the cron routes being handled by commonHandler instead of adminHandler, and a vacuous-true bypass in the permission check for cron creation. By creating a scheduled cron task with Cover=CronCoverAll, Servers=[] and an arbitrary Command, the attacker can execute commands on every server in the global ServerShared map, which includes servers belonging to other tenants. This allows any RoleMember to gain pre-validated RCE on every Nezha-monitored host in the deployment. Affected versions include commit 50dc8e660326b9f22990898142c58b7a5312b42a and earlier on the master branch.

Attack Chain

Attacker gains RoleMember access to the Nezha dashboard, either through admin-granted credentials or self-registration via OAuth2 if enabled.
Attacker obtains a JWT token by authenticating against the /api/v1/login endpoint using their RoleMember credentials.
Attacker creates a webhook notification via POST /api/v1/notification pointing to an attacker-controlled server (e.g., https://attacker.example.com/exfil).
Attacker creates a notification group via POST /api/v1/notification-group and associates the newly created webhook notification with this group.
Attacker crafts a malicious cron task payload using POST /api/v1/cron with servers: [], cover: 1, push_successful: true, and an arbitrary command (e.g., id; hostname; cat /etc/shadow) to be executed on all monitored servers. The notification_group_id field is set to the ID of the attacker’s notification group.
The cron task is scheduled and, upon execution, the crafted command is sent to all monitored Nezha agents.
Each agent executes the command and sends the output back to the Nezha dashboard.
The Nezha dashboard, due to the push_successful: true setting, pushes the command output to the attacker-controlled webhook, allowing the attacker to collect sensitive information from all monitored hosts.

Impact

Successful exploitation allows any RoleMember to achieve cross-tenant RCE on every host monitored by the Nezha dashboard. This can lead to full compromise of all monitored systems, including data exfiltration, privilege escalation, and disruption of services. The vulnerability affects all deployments where RoleMember accounts are enabled, including those with OAuth2 self-registration. The impact is especially severe as the Nezha agent typically runs as root.

Recommendation

Immediately switch /cron write operations to adminHandler to restrict cron task creation and modification to administrators, mitigating unauthorized command injection (reference: cmd/dashboard/controller/controller.go:131-135).
Implement a per-server permission gate in the CronTrigger function to ensure that cron tasks are only executed on servers owned by the user or an administrator. This adds an additional layer of security (reference: service/singleton/crontask.go:133-181).
Reject cron task creation with empty Servers lists when Cover=CronCoverAll to prevent unrestricted command execution across all hosts (reference: cmd/dashboard/controller/cron.go:45-85).

Nezha Monitoring RoleMember SSRF with Full Response Body Reflection

hello@craftedsignal.io — Sat, 23 May 2026 00:11:36 +0000

Nezha Monitoring is affected by a server-side request forgery (SSRF) vulnerability that allows a low-privileged RoleMember user (Role==1) to perform actions normally restricted to RoleAdmin. The vulnerability resides in the notification routes POST /api/v1/notification and PATCH /api/v1/notification/:id, which are accessible to RoleMember users due to being wired through commonHandler instead of adminHandler. By crafting malicious HTTP requests to user-controlled URLs via these routes, attackers can force the Nezha dashboard’s hub to send requests to internal resources. The entire response body, without any size limitation, is then reflected back to the attacker, enabling the exposure of sensitive intranet data and potential denial-of-service (DoS) attacks by targeting large internal files. The vulnerability exists in versions up to commit 50dc8e660326b9f22990898142c58b7a5312b42a on the master branch.

Attack Chain

Attacker obtains a valid RoleMember account, likely through legitimate registration or compromise.
Attacker crafts a malicious HTTP POST request to /api/v1/notification or PATCH /api/v1/notification/:id.
The request includes a JSON payload containing a user-controlled URL parameter pointing to an internal resource (e.g., http://192.168.1.1/admin/index.html or http://169.254.169.254/latest/meta-data/iam/security-credentials/).
The NotificationServerBundle.Send() function is called, which uses either utils.HttpClient or utils.HttpClientSkipTlsVerify (depending on the VerifyTLS setting) to send the request. Critically, the request is sent synchronously, and VerifyTLS can be set to false to bypass TLS certificate validation.
The target internal resource responds to the request. If the response status code is not in the 200-299 range, the entire response body is read via io.ReadAll and included in an error message.
The error message, containing the full response body of the internal resource, is returned to the attacker via newErrorResponse in a JSON response.
The attacker parses the JSON response to extract the reflected content of the internal resource.
If the attacker targets a large internal file, the dashboard may experience a denial-of-service due to excessive memory consumption by io.ReadAll.

Impact

Successful exploitation of this SSRF vulnerability allows a RoleMember to read the contents of internal web pages, potentially exposing sensitive information like API keys, configuration details, or internal application data. The ability to disable TLS verification expands the scope of attack to internal HTTPS endpoints. Furthermore, an attacker can trigger a denial-of-service (DoS) by targeting large internal files, causing the dashboard server to consume excessive memory. The vulnerability is rated as medium severity with a CVSS score of 6.4, considering the low privileges required and potential for limited data exposure and service disruption.

Recommendation

Immediately apply the suggested fix by switching the /notification routes to use adminHandler to restrict access to administrators only. This mitigation directly addresses the root cause by preventing RoleMember users from accessing the vulnerable endpoints (cmd/dashboard/controller/controller.go:121-122).
Implement SSRF hardening measures in the NotificationServerBundle.Send() function as suggested in the advisory. This should include validating the target URL, resolving the host IP address, and enforcing HTTP(S) schemes to prevent requests to arbitrary protocols.
Cap the response body size using io.LimitReader(resp.Body, 4096) within the NotificationServerBundle.Send() function to mitigate the DoS risk associated with reading large internal files (model/notification.go:113-159).
Deploy the provided Sigma rule Detect Nezha Monitoring SSRF Attempt via Notification API to identify attempts to exploit this vulnerability by monitoring requests to the /api/v1/notification endpoint with suspicious URLs.