CVE-2026-101087: Nezha SSRF Vulnerability

CVE-2026-101087 Overview

CVE-2026-101087 is a Server-Side Request Forgery (SSRF) denylist bypass affecting Nezha, an open-source server monitoring and operations dashboard. Versions 2.0.10 through 2.3.2 restrict webhook destinations using an IPv6 denylist that omits two transition ranges: the 6to4 prefix 2002::/16 and the local-use IPv4/IPv6 translation prefix 64:ff9b:1::/48. Addresses in these ranges pass Go's netip.Addr.IsGlobalUnicast check, so the URL validator accepts them. An authenticated user with webhook configuration rights can direct the dashboard to issue HTTP requests to otherwise restricted IPv6 endpoints when the host network routes these ranges non-standardly. Version 2.3.3 (commit d1fcde8e) closes the gap.

Critical Impact
Authenticated attackers may coerce the Nezha dashboard into issuing webhook requests to internal IPv6 endpoints in environments with non-standard routing for IPv6 transition prefixes.

Affected Products

Nezha dashboard version 2.0.10
Nezha dashboard versions 2.1.x through 2.3.2
Deployments using notification or Dynamic DNS (DDNS) webhook features

Discovery Timeline

2026-09-27 - CVE-2026-101087 published to the National Vulnerability Database (NVD)
2026-09-30 - Last updated in NVD database

Technical Details for CVE-2026-101087

Vulnerability Analysis

Nezha validates user-supplied webhook URLs through a restricted HTTP client in pkg/utils/http.go. The validator rejects destinations that resolve to a predefined set of loopback, private, link-local, and reserved IPv6 prefixes. The denylist omitted two IPv6 transition prefixes that can map to IPv4 address space: 2002::/16 (6to4) and 64:ff9b:1::/48 (local-use IPv4/IPv6 translation). Because both ranges report as global unicast per Go's netip.Addr.IsGlobalUnicast, the validator accepted them as safe public destinations.

The weakness is classified as [CWE-918] Server-Side Request Forgery. Exploitation requires an authenticated user with webhook configuration permissions. No demonstrated path reaches IPv4 metadata services, loopback, or RFC1918 ranges directly through this bypass, which bounds the practical impact to environments that route these transition prefixes to internal destinations.

Root Cause

The denylist in pkg/utils/http.go was incomplete. It covered standard private and reserved IPv6 ranges but missed transition prefixes that can tunnel to or translate IPv4 addresses. Reliance on IsGlobalUnicast as the final gate allowed these addresses through because Go treats them as globally routable unicast.

Attack Vector

An authenticated operator configures a notification webhook or DDNS webhook URL containing an IPv6 address inside 2002::/16 or 64:ff9b:1::/48. When the dashboard triggers the webhook, the restricted HTTP client issues the outbound request. On networks that provide unusual routing for 6to4 or translation prefixes, the request may reach an internal service that would otherwise be unreachable.

// Patch in pkg/utils/http.go - block IPv6 transition ranges for webhooks
 	"::1/128",
 	"::ffff:0:0/96",
 	"64:ff9b::/96",
+	"64:ff9b:1::/48",
 	"100::/64",
 	"2001::/23",
 	"2001:db8::/32",
+	"2002::/16",
 	"fc00::/7",
 	"fe80::/10",
 	"ff00::/8",

Source: GitHub commit d1fcde8e

Detection Methods for CVE-2026-101087

Indicators of Compromise

Outbound HTTP requests from the Nezha dashboard host to IPv6 destinations within 2002::/16 or 64:ff9b:1::/48.
Webhook configuration changes authored by non-administrative users that reference IPv6 literal addresses.
Unexpected notification or DDNS payloads delivered to endpoints that do not match the organization's documented webhook receivers.

Detection Strategies

Inspect the Nezha configuration store and audit logs for webhook URLs containing IPv6 literals, particularly those beginning with 2002: or 64:ff9b:1:.
Correlate dashboard outbound connections against the deployed version; versions 2.0.10 through 2.3.2 are in scope.
Alert on dashboard-originated DNS resolutions returning AAAA records inside the two transition prefixes.

Monitoring Recommendations

Enable egress logging on the dashboard host and forward records to a centralized analytics platform for correlation with webhook configuration events.
Baseline normal webhook destinations and alert on deviations, especially new IPv6 destinations.
Review authentication and role assignments for users with webhook configuration privileges on a recurring basis.

How to Mitigate CVE-2026-101087

Immediate Actions Required

Upgrade Nezha to version 2.3.3 or later, which includes commit d1fcde8e blocking both transition prefixes.
Audit existing notification and DDNS webhook URLs and remove any entries containing IPv6 literals in 2002::/16 or 64:ff9b:1::/48.
Restrict webhook configuration permissions to a minimal set of trusted administrators.

Patch Information

The fix is published in Nezha 2.3.3 via commit d1fcde8e in pkg/utils/http.go. The patch adds 64:ff9b:1::/48 and 2002::/16 to the IPv6 denylist used by the restricted HTTP client. Full details are available in the GitHub Security Advisory GHSA-jr2j-7hvh-h4q9 and the VulnCheck SSRF Denylist Advisory.

Workarounds

Place the Nezha dashboard behind an egress firewall that denies outbound traffic to 2002::/16 and 64:ff9b:1::/48 until the upgrade is applied.
Disable IPv6 on the dashboard host where IPv4-only operation is acceptable.
Verify that network routing does not forward 6to4 or local-use translation prefixes toward internal infrastructure.

bash

# Example egress controls using ip6tables to block IPv6 transition ranges
ip6tables -A OUTPUT -d 2002::/16 -j REJECT
ip6tables -A OUTPUT -d 64:ff9b:1::/48 -j REJECT