CVE-2026-101087: Nezha 2.0.10 through 2.3.2 SSRF Denylist Bypass IPv6
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Nezhato a version that resolves this vulnerability.Fixed in 2.3.3Patch d1fcde8e
Event History
Frequently Asked Questions
Who can exploit this issue in practice?
An authenticated user who is allowed to configure notification or DDNS webhook URLs may be able to exploit it. Exploitation also depends on the dashboard network providing unusual or non-standards-compliant routing for the affected IPv6 transition ranges.
Are default or typical deployments likely to be exposed to internal IPv4 services?
No direct path to IPv4 metadata, loopback, or private-network HTTP requests has been demonstrated. The reported bypass is limited to the 6to4 range 2002::/16 and the local-use IPv4/IPv6 translation range 64:ff9b:1::/48, and requires routing behavior that may not exist in typical environments.
What should be done if upgrading is not immediately possible?
Restrict webhook configuration privileges to trusted authenticated users. Review configured notification and DDNS webhook URLs and prevent use of addresses in 2002::/16 and 64:ff9b:1::/48.
How can I determine whether an installation is affected?
Nezha versions 2.0.10 through 2.3.2 are affected. Version 2.3.3 blocks both affected IPv6 prefixes.