{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","feed_url":"https://feed.craftedsignal.io/tags/nezha/feed.json","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["nezha"],"_cs_severities":["critical"],"_cs_tags":["rce","privilege-escalation","cron","authorization","nezha"],"_cs_type":"advisory","_cs_vendors":["Nezha"],"content_html":"\u003cp\u003eThe Nezha monitoring dashboard is vulnerable to a cross-tenant RCE. A \u003ccode\u003eRoleMember\u003c/code\u003e (Role==1), even one self-registered via OAuth2, can exploit insufficient authorization checks in the cron task creation process (\u003ccode\u003ePOST /api/v1/cron\u003c/code\u003e and \u003ccode\u003ePATCH /api/v1/cron/:id\u003c/code\u003e). The vulnerability stems from the cron routes being handled by \u003ccode\u003ecommonHandler\u003c/code\u003e instead of \u003ccode\u003eadminHandler\u003c/code\u003e, and a vacuous-true bypass in the permission check for cron creation. By creating a scheduled cron task with \u003ccode\u003eCover=CronCoverAll, Servers=[]\u003c/code\u003e and an arbitrary \u003ccode\u003eCommand\u003c/code\u003e, the attacker can execute commands on every server in the global \u003ccode\u003eServerShared\u003c/code\u003e map, which includes servers belonging to other tenants. This allows any \u003ccode\u003eRoleMember\u003c/code\u003e to gain pre-validated RCE on every Nezha-monitored host in the deployment. Affected versions include commit \u003ccode\u003e50dc8e660326b9f22990898142c58b7a5312b42a\u003c/code\u003e and earlier on the \u003ccode\u003emaster\u003c/code\u003e branch.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains \u003ccode\u003eRoleMember\u003c/code\u003e access to the Nezha dashboard, either through admin-granted credentials or self-registration via OAuth2 if enabled.\u003c/li\u003e\n\u003cli\u003eAttacker obtains a JWT token by authenticating against the \u003ccode\u003e/api/v1/login\u003c/code\u003e endpoint using their \u003ccode\u003eRoleMember\u003c/code\u003e credentials.\u003c/li\u003e\n\u003cli\u003eAttacker creates a webhook notification via \u003ccode\u003ePOST /api/v1/notification\u003c/code\u003e pointing to an attacker-controlled server (e.g., \u003ccode\u003ehttps://attacker.example.com/exfil\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eAttacker creates a notification group via \u003ccode\u003ePOST /api/v1/notification-group\u003c/code\u003e and associates the newly created webhook notification with this group.\u003c/li\u003e\n\u003cli\u003eAttacker crafts a malicious cron task payload using \u003ccode\u003ePOST /api/v1/cron\u003c/code\u003e with \u003ccode\u003eservers: []\u003c/code\u003e, \u003ccode\u003ecover: 1\u003c/code\u003e, \u003ccode\u003epush_successful: true\u003c/code\u003e, and an arbitrary command (e.g., \u003ccode\u003eid; hostname; cat /etc/shadow\u003c/code\u003e) to be executed on all monitored servers. The \u003ccode\u003enotification_group_id\u003c/code\u003e field is set to the ID of the attacker\u0026rsquo;s notification group.\u003c/li\u003e\n\u003cli\u003eThe cron task is scheduled and, upon execution, the crafted command is sent to all monitored Nezha agents.\u003c/li\u003e\n\u003cli\u003eEach agent executes the command and sends the output back to the Nezha dashboard.\u003c/li\u003e\n\u003cli\u003eThe Nezha dashboard, due to the \u003ccode\u003epush_successful: true\u003c/code\u003e setting, pushes the command output to the attacker-controlled webhook, allowing the attacker to collect sensitive information from all monitored hosts.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation allows any \u003ccode\u003eRoleMember\u003c/code\u003e 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 \u003ccode\u003eRoleMember\u003c/code\u003e accounts are enabled, including those with OAuth2 self-registration. The impact is especially severe as the Nezha agent typically runs as root.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eImmediately switch \u003ccode\u003e/cron\u003c/code\u003e write operations to \u003ccode\u003eadminHandler\u003c/code\u003e to restrict cron task creation and modification to administrators, mitigating unauthorized command injection (reference: \u003ccode\u003ecmd/dashboard/controller/controller.go:131-135\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eImplement a per-server permission gate in the \u003ccode\u003eCronTrigger\u003c/code\u003e 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: \u003ccode\u003eservice/singleton/crontask.go:133-181\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eReject cron task creation with empty \u003ccode\u003eServers\u003c/code\u003e lists when \u003ccode\u003eCover=CronCoverAll\u003c/code\u003e to prevent unrestricted command execution across all hosts (reference: \u003ccode\u003ecmd/dashboard/controller/cron.go:45-85\u003c/code\u003e).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-23T00:19:38Z","date_published":"2026-05-23T00:19:38Z","id":"https://feed.craftedsignal.io/briefs/2026-05-nezha-rce/","summary":"A RoleMember in Nezha monitoring dashboard can achieve cross-tenant remote code execution by injecting arbitrary commands into cron tasks due to insufficient authorization checks, impacting all monitored hosts in the deployment.","title":"Nezha Monitoring Cross-Tenant RCE via Cron Task Injection","url":"https://feed.craftedsignal.io/briefs/2026-05-nezha-rce/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Nezha Monitoring"],"_cs_severities":["medium"],"_cs_tags":["ssrf","nezha","vulnerability"],"_cs_type":"advisory","_cs_vendors":["GitHub"],"content_html":"\u003cp\u003eNezha Monitoring is affected by a server-side request forgery (SSRF) vulnerability that allows a low-privileged \u003ccode\u003eRoleMember\u003c/code\u003e user (Role==1) to perform actions normally restricted to \u003ccode\u003eRoleAdmin\u003c/code\u003e. The vulnerability resides in the notification routes \u003ccode\u003ePOST /api/v1/notification\u003c/code\u003e and \u003ccode\u003ePATCH /api/v1/notification/:id\u003c/code\u003e, which are accessible to \u003ccode\u003eRoleMember\u003c/code\u003e users due to being wired through \u003ccode\u003ecommonHandler\u003c/code\u003e instead of \u003ccode\u003eadminHandler\u003c/code\u003e. By crafting malicious HTTP requests to user-controlled URLs via these routes, attackers can force the Nezha dashboard\u0026rsquo;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 \u003ccode\u003e50dc8e660326b9f22990898142c58b7a5312b42a\u003c/code\u003e on the \u003ccode\u003emaster\u003c/code\u003e branch.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker obtains a valid \u003ccode\u003eRoleMember\u003c/code\u003e account, likely through legitimate registration or compromise.\u003c/li\u003e\n\u003cli\u003eAttacker crafts a malicious HTTP POST request to \u003ccode\u003e/api/v1/notification\u003c/code\u003e or \u003ccode\u003ePATCH /api/v1/notification/:id\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe request includes a JSON payload containing a user-controlled \u003ccode\u003eURL\u003c/code\u003e parameter pointing to an internal resource (e.g., \u003ccode\u003ehttp://192.168.1.1/admin/index.html\u003c/code\u003e or \u003ccode\u003ehttp://169.254.169.254/latest/meta-data/iam/security-credentials/\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eNotificationServerBundle.Send()\u003c/code\u003e function is called, which uses either \u003ccode\u003eutils.HttpClient\u003c/code\u003e or \u003ccode\u003eutils.HttpClientSkipTlsVerify\u003c/code\u003e (depending on the \u003ccode\u003eVerifyTLS\u003c/code\u003e setting) to send the request. Critically, the request is sent synchronously, and \u003ccode\u003eVerifyTLS\u003c/code\u003e can be set to false to bypass TLS certificate validation.\u003c/li\u003e\n\u003cli\u003eThe 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 \u003ccode\u003eio.ReadAll\u003c/code\u003e and included in an error message.\u003c/li\u003e\n\u003cli\u003eThe error message, containing the full response body of the internal resource, is returned to the attacker via \u003ccode\u003enewErrorResponse\u003c/code\u003e in a JSON response.\u003c/li\u003e\n\u003cli\u003eThe attacker parses the JSON response to extract the reflected content of the internal resource.\u003c/li\u003e\n\u003cli\u003eIf the attacker targets a large internal file, the dashboard may experience a denial-of-service due to excessive memory consumption by \u003ccode\u003eio.ReadAll\u003c/code\u003e.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this SSRF vulnerability allows a \u003ccode\u003eRoleMember\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eImmediately apply the suggested fix by switching the \u003ccode\u003e/notification\u003c/code\u003e routes to use \u003ccode\u003eadminHandler\u003c/code\u003e to restrict access to administrators only. This mitigation directly addresses the root cause by preventing \u003ccode\u003eRoleMember\u003c/code\u003e users from accessing the vulnerable endpoints (\u003ccode\u003ecmd/dashboard/controller/controller.go:121-122\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eImplement SSRF hardening measures in the \u003ccode\u003eNotificationServerBundle.Send()\u003c/code\u003e 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.\u003c/li\u003e\n\u003cli\u003eCap the response body size using \u003ccode\u003eio.LimitReader(resp.Body, 4096)\u003c/code\u003e within the \u003ccode\u003eNotificationServerBundle.Send()\u003c/code\u003e function to mitigate the DoS risk associated with reading large internal files (\u003ccode\u003emodel/notification.go:113-159\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eDeploy the provided Sigma rule \u003ccode\u003eDetect Nezha Monitoring SSRF Attempt via Notification API\u003c/code\u003e to identify attempts to exploit this vulnerability by monitoring requests to the \u003ccode\u003e/api/v1/notification\u003c/code\u003e endpoint with suspicious URLs.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-23T00:11:36Z","date_published":"2026-05-23T00:11:36Z","id":"https://feed.craftedsignal.io/briefs/2026-05-nezha-ssrf/","summary":"Nezha Monitoring is vulnerable to a server-side request forgery (SSRF) vulnerability, where a low-privilege RoleMember user can call notification routes and send HTTP requests to a user-controlled URL, with the entire response body reflected back to the caller, potentially exposing intranet resources and causing denial of service.","title":"Nezha Monitoring RoleMember SSRF with Full Response Body Reflection","url":"https://feed.craftedsignal.io/briefs/2026-05-nezha-ssrf/"}],"language":"en","title":"CraftedSignal Threat Feed — Nezha","version":"https://jsonfeed.org/version/1.1"}