{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","feed_url":"https://feed.craftedsignal.io/products/nezha-monitoring/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 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 Monitoring","version":"https://jsonfeed.org/version/1.1"}