CVE-2026-46717: Nezha Monitoring SSRF via Improper Access Control (v1.4.0–2.0.7)

Technical summary

Nezha Monitoring's notification management endpoints (/api/v1/notification via POST and /api/v1/notification/:id via PATCH) are routed through commonHandler middleware rather than the more restrictive adminHandler. This design flaw permits RoleMember users (role value 1) to invoke handlers intended for RoleAdmin users (role value 0). When these endpoints are called, the application synchronously executes an HTTP request to a caller-supplied URL and reflects the complete response body back without filtering or size restrictions, even on non-2xx responses. This creates a direct SSRF vulnerability where member-level authenticated users can pivot to internal systems, cloud metadata services, or other backend infrastructure. The vulnerability affects all installations running versions 1.4.0 through 2.0.7.

Business impact

Organizations running affected Nezha Monitoring versions face a significant insider risk, as any team member granted monitoring access—including contractors or junior staff—can enumerate and potentially exfiltrate data from internal systems and cloud infrastructure. An attacker could weaponize this to discover private IP ranges, access cloud metadata services to retrieve temporary credentials, or map the organization's internal network topology. The combination of high confidentiality impact and the ability to pivot across security boundaries (CVSS severity score of HIGH) makes this a critical control gap in asset visibility and monitoring platforms, which are often positioned in DMZ or hybrid environments with sight lines to sensitive infrastructure.

Affected systems

Nezha Monitoring version 1.4.0 through version 2.0.7 (inclusive) are affected. Version 2.0.8 and later contain the patch. Self-hosted deployments are the primary exposure vector; cloud-hosted or SaaS variants (if they exist) would inherit the same risk if running vulnerable code. Any Nezha instance accessible to multiple users where role separation is important should be reviewed for exposure.

Exploitability

Exploitation requires valid member-level credentials to the Nezha dashboard—a low barrier compared to unauthenticated attacks, but a meaningful one. An insider, compromised account, or developer on an internal team could trigger the vulnerability with a single API call specifying a target URL. The attack is trivial to execute: a simple HTTP POST or PATCH request with a JSON payload pointing to an internal service. No complex interaction, social engineering, or race conditions are needed. The synchronous HTTP request design means the attacker receives immediate feedback on whether the target is reachable and can observe response content in real time, making reconnaissance highly efficient.

Remediation

Upgrade Nezha Monitoring to version 2.0.8 or later immediately. Before upgrading, restrict member-level user access to Nezha instances if possible, or ensure that only highly trusted individuals hold member roles. Review historical audit logs for any suspicious calls to /api/v1/notification endpoints from non-admin users. For organizations unable to patch immediately, implement network-layer controls: restrict outbound HTTP/HTTPS from Nezha processes to only approved destinations, and block access to cloud metadata endpoints (e.g., 169.254.169.254).

Patch guidance

Update Nezha Monitoring to version 2.0.8 or later. Consult the official Nezha GitHub repository and release notes to verify the exact patch and any additional changes in the target version. Test the upgrade in a non-production environment first, as monitoring tools are critical to operational visibility. No configuration changes are required post-patch; the fix is purely in the access control logic.

Detection guidance

Monitor application logs and access logs for unusual POST or PATCH requests to /api/v1/notification from member-level users, especially if accompanied by requests to internal IPs (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) or cloud metadata endpoints. Look for responses with large body sizes or error responses (4xx, 5xx) that may indicate reconnaissance probing. Network monitoring tools should flag outbound connections from Nezha processes to unexpected destinations. If available, audit the HTTP requests sent to external URLs and check for patterns consistent with SSRF attempts (e.g., repeated probes to different internal subnets, requests to 169.254.169.254, or connections to internal database ports).

Why prioritize this

This vulnerability merits immediate attention because: (1) it grants insider-initiated SSRF capability in a trusted security tool, (2) the CVSS score is 7.7 (HIGH), reflecting high confidentiality impact and network scope crossing, (3) there is no exploit complexity—any member-level user can trigger it, (4) it exposes internal infrastructure without leaving obvious traces in many logging scenarios, and (5) Nezha Monitoring is often deployed with visibility into critical backend systems. While not yet in the CISA KEV catalog, the ease of exploitation and the value of the exposed information make it a near-term priority for patching.

Risk score, explained

CVSS 3.1 score of 7.7 (HIGH) reflects: Network-based attack vector (AV:N), low attack complexity (AC:L), and low privilege requirements (PR:L, i.e., an authenticated member role). The scope is changed (S:C), meaning the SSRF can cross trust boundaries to access other systems. Confidentiality impact is high (C:H) because response bodies are fully reflected without filtering, enabling data exfiltration. Integrity and availability impacts are rated none (I:N, A:N) because this vulnerability is read-only in its primary exploitation form, though integrity could be at risk if the targeted internal service processes malicious input. The lack of user interaction (UI:N) and the broad network accessibility push the score into the HIGH band rather than MEDIUM.

Frequently asked questions