CVE-2026-47268: Nezha Monitoring SSRF in DDNS Webhooks (v2.0.10 Patch)

Technical summary

CVE-2026-47268 is a Server-Side Request Forgery (SSRF) vulnerability in Nezha Monitoring versions 0.20.0 through 2.0.9. The vulnerability exists in the DDNS provider webhook functionality, which allows authenticated users to specify arbitrary webhook endpoints, HTTP methods, request bodies, and headers. When DDNS is triggered on a server using an attacker-controlled profile, the dashboard process executes the configured HTTP request via utils.HttpClient without applying the SSRF protections that are enforced for standard notification webhooks. This permits an authenticated attacker to craft requests targeting RFC 1918 addresses, localhost, or link-local addresses. The response body is not leaked in the confirmed exploitation path, making this a blind SSRF primitive suitable for triggering state changes in internal services or exploiting time-based detection methods.

Business impact

Organizations running Nezha Monitoring should assess exposure based on deployment model and access controls. If the dashboard is internet-facing or accessible to untrusted authenticated users, this vulnerability could be chained with account compromise or insider threats to probe or manipulate backend services—such as databases, caches, or management APIs—that are reachable only from the dashboard host. Blind SSRF attacks can be leveraged to trigger password reset flows, modify monitoring configurations, or enumerate internal service availability. The requirement for authentication and an owned server reduces the immediate blast radius, but multi-tenant or shared deployments warrant elevated concern.

Affected systems

Nezha Monitoring versions 0.20.0 through 2.0.9 are affected. Version 2.0.10 includes the patch. Deployments running versions prior to 2.0.10 should be prioritized for upgrade. Self-hosted instances that expose the dashboard UI to untrusted network segments or support multiple users with different privilege levels face the highest risk.

Exploitability

Exploitation requires an authenticated Nezha dashboard account and control of at least one server registered in the monitoring system. The attacker configures a DDNS profile with a crafted webhook targeting internal services, then triggers DDNS on their controlled server. The dashboard process automatically issues the request, allowing enumeration and state-changing attacks against internal network services. No user interaction or additional authentication is needed once the malicious profile is in place. The CVSS score of 6.4 (MEDIUM) reflects the authentication requirement and limited information disclosure, though the blind SSRF nature and multi-stage exploit chain reduce practical exploitability compared to direct RCE or full SSRF with response exfiltration.

Remediation

Upgrade Nezha Monitoring to version 2.0.10 or later immediately. The patch applies the same SSRF protections used by notification webhooks to the DDNS webhook handler, preventing requests to private IP ranges and loopback addresses. If immediate patching is not feasible, restrict dashboard access to trusted internal networks only, enforce strong authentication and role-based access controls to limit who can create or modify DDNS profiles, and monitor outbound HTTP connections from the dashboard process for anomalous destinations.

Patch guidance

Version 2.0.10 is the patched release. Verify the version in your deployment (typically accessible via the dashboard UI or by checking the running container image tag) and update using your standard Nezha update procedure. If you are on a version older than 0.20.0, you are not affected by this specific vulnerability but should review your current version for other known issues. Test the patch in a non-production environment first to confirm monitoring functionality is unaffected, then roll out to production according to your change management process.

Detection guidance

Monitor dashboard process outbound HTTP connections for requests to RFC 1918 addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), 127.0.0.1, or link-local addresses (169.254.0.0/16). Log and review DDNS profile creation and modification events, particularly any with unusual webhook URLs or headers. Correlate these logs with network traffic captures or firewall logs showing unexpected internal connections initiated by the dashboard host. In environments with network segmentation, ensure the dashboard host cannot reach sensitive internal services; if it must access them for legitimate monitoring, apply additional authentication or API key validation at the destination service.

Why prioritize this

Although the CVSS score is MEDIUM, prioritization should account for deployment context. Internet-facing or multi-tenant Nezha instances should be patched urgently due to the ease of exploitation once authenticated. Organizations with strong network segmentation and restricted dashboard access can deprioritize slightly but should not defer patching indefinitely. The blind SSRF nature limits immediate destructive potential but enables reconnaissance and state-changing attacks that could accelerate lateral movement or privilege escalation in a compromised environment.

Risk score, explained

CVSS 6.4 reflects: (1) network attack vector and low complexity—any authenticated user can exploit this; (2) low privilege requirement and no user interaction; (3) scope change, meaning the vulnerability impacts resources beyond the vulnerable component (internal services); (4) low confidentiality and low integrity impact due to blind response and no direct data exfiltration. The score does not assume a full compromise of internal services, only the ability to issue crafted requests to them. Organizations with sensitive internal services reachable from the dashboard or with a large authenticated user base should treat this as functionally higher risk.

Frequently asked questions