CVE-2026-101087 in Nezha
Summary
by MITRE • 09/28/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/28/2026
The vulnerability identified in Nezha versions 2.0.10 through 2.3.2 stems from an incomplete implementation of a security control designed to prevent server-side request forgery, commonly referred to as SSRF. The application utilizes a restricted HTTP client for validating user-configurable notification and DDNS webhook URLs, aiming to restrict outbound connections to safe, public internet destinations while blocking access to internal or metadata services. This validation mechanism relies on checking the target IP address against a denylist of known private, loopback, and link-local ranges. However, the implementation failed to account for specific IPv6 transition prefixes that are technically classified as global unicast addresses by standard networking libraries but can be used to bypass network-level restrictions under certain routing conditions.
The core technical flaw lies in the handling of two specific IPv6 address blocks: the 2002::/16 prefix, which is reserved for 6to4 transition mechanisms, and the 64:ff9b:1::/48 prefix, used for Well-Known Prefix translation. In Go's netip package, addresses within these ranges satisfy the IsGlobalUnicast check because they are not explicitly marked as private or link-local in standard definitions. Consequently, the URL validator accepted URLs pointing to these IPv6 addresses without triggering a block. This oversight creates a potential bypass vector where an attacker can direct the application to send HTTP requests to endpoints that might be reachable via non-standard routing configurations within the host's network environment.
From an operational impact perspective, this vulnerability allows authenticated users with access to configure webhooks or DDNS settings to potentially trigger outbound HTTP requests from the Nezha dashboard server to internal services or metadata endpoints. The risk is contingent upon the specific network architecture of the deployment; if the dashboard operates in a cloud environment or local network where IPv6 transition addresses are routed internally rather than externally, an attacker could exploit this misconfiguration to access sensitive internal APIs, database interfaces, or instance metadata services that would otherwise be protected by perimeter defenses. While no direct path to standard IPv4 private ranges like 192.168.x.x or loopback addresses was demonstrated in the default configuration, the existence of a bypass mechanism for global unicast checks represents a significant deviation from secure coding practices regarding SSRF prevention.
This vulnerability aligns with CWE-918, Server-Side Request Forgery (SSRF), specifically involving flawed logic in URL validation and IP address filtering. It also relates to CWE-20, Improper Input Validation, as the application failed to correctly validate the semantic meaning of the provided IPv6 addresses against security policies rather than just their technical classification. In terms of adversary tactics, this could facilitate ATT&CK technique T1598, Phishing for Information within a Multi-Tenant Environment, or more directly T1071, Application Layer Protocol, if used to exfiltrate data via DNS or HTTP channels from restricted networks. The vulnerability highlights the critical importance of maintaining comprehensive denylists that include all potential bypass vectors, including less common IPv6 transition ranges, when implementing SSRF mitigations.
The issue has been resolved in Nezha version 2.3.3 through commit d1fcde8e, which explicitly adds both the 2002::/16 and 64:ff9b:1::/48 prefixes to the blocked address list. To mitigate this risk immediately for users unable to upgrade, it is recommended to restrict outbound traffic from the Nezha server at the network level using firewall rules that block access to these specific IPv6 ranges. Additionally, organizations should enforce strict egress filtering policies and consider implementing a web application firewall with SSRF detection capabilities to provide an additional layer of defense against similar bypass attempts in other applications. Regular audits of URL validation logic are essential to ensure that security controls remain effective against evolving network addressing schemes and transition technologies.