CVE-2026-46717: Nezha Monitoring SSRF Vulnerability

CVE-2026-46717 Overview

CVE-2026-46717 is a broken authorization vulnerability [CWE-863] in Nezha Monitoring, a self-hostable server and website monitoring tool. The flaw affects versions from 1.4.0 up to but not including 2.0.8. The notification API endpoints POST /api/v1/notification and PATCH /api/v1/notification/:id are routed through commonHandler instead of adminHandler. This routing mistake allows any authenticated RoleMember user (Role==1) to invoke functionality that should be restricted to RoleAdmin (Role==0). The handlers synchronously send HTTP requests to attacker-controlled URLs and reflect the entire response body back to the caller without size limits.

Critical Impact
A low-privileged member account can coerce the Nezha dashboard into making arbitrary outbound HTTP requests and exfiltrate internal response bodies, enabling server-side request forgery against internal services.

Affected Products

Nezha Monitoring versions 1.4.0 through 2.0.7
Self-hosted Nezha dashboard deployments exposing the notification API
Multi-tenant Nezha instances with RoleMember user accounts

Discovery Timeline

2026-06-12 - CVE-2026-46717 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2026-46717

Vulnerability Analysis

Nezha's dashboard implements role-based access control with two tiers: RoleAdmin (Role==0) and RoleMember (Role==1). Administrative endpoints are expected to pass through adminHandler, which enforces the role check. The notification create and update endpoints were instead wired through commonHandler, which only verifies authentication. Any logged-in member can therefore reach handlers intended for administrators.

The handlers accept a user-supplied URL and synchronously issue an HTTP request to it as part of validating the notification target. When the upstream server returns any non-2xx status code, the dashboard reflects the entire response body back to the caller. No size limits, content-type restrictions, or response truncation are applied.

Root Cause

The root cause is a routing-layer authorization mistake. The handler chain selected for notification mutations does not include the administrative role check, breaking the principle of least privilege. This maps to [CWE-863] Incorrect Authorization. The secondary issue is that response bodies from outbound probes are reflected verbatim to the requester, turning a validation step into a server-side request forgery primitive.

Attack Vector

An attacker with a low-privileged member account submits a notification payload pointing at an internal URL such as a cloud metadata service, internal admin API, or file-protocol endpoint. The dashboard fetches the URL server-side and returns the response body in the error message. The attacker iterates through internal hostnames and ports to map the internal network and harvest sensitive content. Because the response body is unbounded, large internal documents can be exfiltrated through a single request. See the GitHub Security Advisory for the patch detail.

Detection Methods for CVE-2026-46717

Indicators of Compromise

Requests to /api/v1/notification or /api/v1/notification/:id originating from non-admin session cookies
Outbound HTTP requests from the Nezha dashboard process targeting RFC1918 ranges, loopback, or cloud metadata endpoints such as 169.254.169.254
Notification configuration entries containing URLs pointing to internal services rather than known notification providers

Detection Strategies

Correlate authenticated session role with HTTP method and path in dashboard access logs to flag member-role calls against notification mutation endpoints
Inspect Nezha process egress traffic for connections to internal IP ranges that do not match legitimate notification destinations
Review notification entries created or modified between version deployment and the 2.0.8 upgrade for suspicious URLs

Monitoring Recommendations

Enable verbose audit logging on the Nezha API gateway and forward to a centralized log platform for retention
Alert on repeated non-2xx responses from the notification endpoints, which indicate probing for internal services
Track creation rate of notification objects per user account and baseline against normal administrative behavior

How to Mitigate CVE-2026-46717

Immediate Actions Required

Upgrade Nezha Monitoring to version 2.0.8 or later, which routes the affected endpoints through adminHandler
Audit existing member accounts and revoke access for users who do not require dashboard access
Review all notification configurations and remove entries with URLs pointing to internal infrastructure

Patch Information

The maintainers patched this issue in Nezha Monitoring version 2.0.8 by moving POST /api/v1/notification and PATCH /api/v1/notification/:id to the adminHandler chain. Details are available in the Nezha GHSA-w4g9-mxgg-j532 advisory.

Workarounds

Restrict dashboard access at the network layer to administrators only until the upgrade is applied
Place the Nezha dashboard behind a reverse proxy that blocks the notification endpoints for non-admin sessions
Use egress firewall rules to prevent the Nezha process from reaching internal IP ranges and cloud metadata services

bash

# Egress restriction example using iptables on the Nezha host
iptables -A OUTPUT -m owner --uid-owner nezha -d 169.254.169.254 -j REJECT
iptables -A OUTPUT -m owner --uid-owner nezha -d 10.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner nezha -d 172.16.0.0/12 -j REJECT
iptables -A OUTPUT -m owner --uid-owner nezha -d 192.168.0.0/16 -j REJECT