Nezha versions 2.0.10 through 2.3.2 use a restricted HTTP client to validate user-configurable notification and DDNS webhook URLs. However, the denylist did not include IPv6 transition ranges 2002::/16 (6to4 prefix) and 64:ff9b:1::/48 (IPv4/IPv6 translation prefix). Because these addresses pass Go's netip.Addr.IsGlobalUnicast check, the URL validator accepted them. This allows an authenticated user with webhook configuration privileges to cause the dashboard to issue HTTP requests to IPv6 endpoints that are normally restricted, but only if the dashboard's network routing allows access to these unusual transition ranges. No direct exploitation to access IPv4 metadata, loopback, or private network HTTP endpoints has been demonstrated. The vulnerability is fixed in version 2.3.3 by blocking these IPv6 prefixes.

An authenticated user able to configure webhooks can cause the Nezha dashboard to send HTTP requests to IPv6 endpoints within the 6to4 and IPv4/IPv6 translation address ranges that were previously not blocked. This could potentially allow SSRF attacks targeting internal or otherwise restricted IPv6 resources if the network routing is non-standard or unusual. However, no direct path to sensitive IPv4 internal endpoints or metadata services has been demonstrated. The CVSS 4.0 score is 5.3 (medium severity), reflecting the limited scope and requirement for authentication.

Upgrade Nezha to version 2.3.3 or later, which includes a fix blocking the problematic IPv6 transition prefixes 2002::/16 and 64:ff9b:1::/48 in the webhook URL validation. This official fix fully mitigates the vulnerability. No additional action is required if running the fixed version.