Description

Nezha versions 2.0.10 through 2.3.2 use a restricted HTTP client to validate user-configurable notification and DDNS webhook URLs, but the denylist did not cover IPv6 transition ranges — specifically the 6to4 prefix 2002::/16 and the local-use IPv4/IPv6 translation prefix 64:ff9b:1::/48. Because such addresses satisfy Go's netip.Addr.IsGlobalUnicast check, the URL validator accepted them. An authenticated user able to configure a webhook may be able to cause the dashboard to issue requests to an otherwise restricted IPv6 endpoint, but only where the dashboard's network provides unusual or non-standards-compliant routing for these transition ranges; no direct path to an IPv4 metadata, loopback, or private-network HTTP request has been demonstrated. The issue is fixed in version 2.3.3 (commit d1fcde8e), which blocks both prefixes.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.3",
  "pubDate": "2026-09-27T21:17:02.587Z",
  "pubdate": "2026-09-27T21:17:02.587Z",
  "executiveSummary": "Nezha versions 2.0.10 through 2.3.2 are susceptible to a Server-Side Request Forgery (SSRF) vulnerability due to an incomplete blocklist within its URL validation mechanism.\nThe vulnerability involves the failure to restrict specific IPv6 transition addresses that bypass the application's global unicast filtering logic.\nAuthenticated users with privileges to configure webhook or DDNS settings can leverage this flaw to force the Nezha dashboard to perform unauthorized HTTP requests to restricted IPv6 network endpoints.\nThe risk is contingent upon the underlying infrastructure's routing configuration regarding IPv6 transition mechanisms, such as 6to4 or NAT64 prefixes.\nThis vulnerability is classified as an authorization bypass resulting in SSRF, potentially allowing an attacker to probe internal or restricted network segments reachable via these specific IPv6 transition ranges.\nRemediation requires upgrading the dashboard to version 2.3.3, which implements explicit blocking of the affected address prefixes.",
  "technicalDetails": "The vulnerability resides in the validation logic responsible for inspecting user-supplied notification and DDNS webhook URLs within the Nezha dashboard.\nThe application utilizes Go's netip.Addr.IsGlobalUnicast method to sanitize requested endpoints. While intended to prevent SSRF against loopback, link-local, and private address spaces, the implementation failed to account for specific IPv6 transition prefixes.\nSpecifically, the denylist omission includes the 6to4 prefix (2002::/16) and the well-known IPv4/IPv6 translation prefix (64:ff9b:1::/48).\nThese prefixes are perceived as valid global unicast addresses by the netip.Addr library, allowing them to bypass the application's security checks despite their capability to facilitate traffic to restricted segments depending on the host's network stack configuration.\nThe attack flow requires an authenticated user to have sufficient privileges to modify webhook or DDNS webhook settings. By crafting a malicious webhook URL using these IPv6 prefixes, the attacker forces the Nezha dashboard process to initiate an outbound HTTP request to the target destination.\nThe impact is heavily dependent on the host environment's routing table. If the server infrastructure supports the mentioned transition mechanisms, the request could be routed to internal services or network segments that the developer intended to be isolated from external-facing dashboard features.\nAlthough the vulnerability does not directly permit access to IPv4 loopback or standard private network ranges, it enables an attacker to manipulate the dashboard into acting as a proxy for network reconnaissance or exploitation against infrastructure reachable via IPv6 transition protocols.\nThe flaw was addressed in version 2.3.3 (commit d1fcde8e) by explicitly hardening the validator to treat these specific IPv6 transition prefixes as restricted targets, effectively nullifying the bypass vector."
}