Nezha CVE-2026-101087

Requires an authenticated Nezha user (PR:L) with access to configure a notification or DDNS webhook URL. The attacker must supply an IPv6 literal in the 6to4 prefix 2002::/16 or the local-use NAT64 prefix 64:ff9b:1::/48, which the pre-2.3.3 denylist failed to block. Critically, meaningful exploitation is limited to deployments whose network provides unusual or non-standards-compliant routing for these IPv6 transition ranges; on standards-compliant networks these addresses do not resolve to internal targets, and the advisory confirms no path to IPv4 metadata, loopback, or private-network requests was demonstrated. Affects Nezha 2.0.10 through 2.3.2; fixed in 2.3.3 (commit d1fcde8e).

This is a genuinely low-priority, high-caveat SSRF. The vendor CVSS 4.0 score is 5.3 (medium) with vector AV:N/AC:L/PR:L/UI:N/VC:N/VI:L/SC:L, and CWE-918 (SSRF) is the correct classification. However, the description itself is unusually candid about the weakness of the finding: the bypass only reaches otherwise-restricted IPv6 endpoints 'where the dashboard's network provides unusual or non-standards-compliant routing for these transition ranges,' and explicitly states 'no direct path to an IPv4 metadata, loopback, or private-network HTTP request has been demonstrated.' That materially undercuts the classic SSRF-to-cloud-metadata impact that makes such bugs dangerous. There is no EPSS score, no CISA KEV listing, and no public exploit code provided - exploitation status is 'no public exploit identified at time of analysis.' Exploitation is authenticated (PR:L requires a valid dashboard user able to configure a webhook), and effective attacks require attacker-favorable, non-standard routing of 6to4/NAT64 prefixes on the victim's network, so the real-world AC is higher than the vendor's AC:L implies. Net: a real, patch-worthy SSRF denylist-completeness gap, but closer to a hardening fix than an urgent exploitable threat - treat as low priority absent evidence of exploitable routing in the specific deployment.

An authenticated Nezha dashboard user with permission to configure a notification or DDNS webhook sets the target URL to an IPv6 literal in the 6to4 (2002::/16) or local-use NAT64 (64:ff9b:1::/48) range, e.g. http://[64:ff9b:1::a9fe:a9fe]/metadata, which the flawed denylist accepts because Go's netip.Addr.IsGlobalUnicast returns true. The dashboard then issues an HTTP request to that address; only if the surrounding network non-standardly routes these transition prefixes toward an internal or link-local destination does the attacker gain any restricted reach. No public exploit code exists, and no path to IPv4 metadata/loopback/private ranges has been demonstrated.