CVE-2026-79913: Server-Side Request Forgery Bypass via IPv6 Transition Addresses in Cloudreve

Cloudreve is a self-hosted file management and sharing system that provides users with a comprehensive utility for managing files across various storage backends. Among its capabilities, the remote download manager permits users to instruct the server to fetch files directly from external URLs. To prevent users from utilizing this capability to map or interact with the server's local subnet, Cloudreve routes remote download requests through a strict server-side request forgery (SSRF) validation guard.

This security guard is implemented via the ValidateExternalURL function located inside pkg/request/ssrf.go. The validation step is intended to identify and block connections targeting loopback, private, link-local, or cloud metadata IP ranges. By verifying that resolved addresses do not reside inside these prohibited boundaries, the application aims to isolate user-supplied requests from internal infrastructure.

However, a logic flaw in the verification process permits a complete bypass of these network restrictions. Because the input validation step does not decode or normalize various IPv4-in-IPv6 transition formats before inspecting their routing characteristics, attackers can frame internal IPv4 addresses within globally-routable IPv6 envelopes. This mismatch exposes internal HTTP API endpoints, administrative interfaces, and sensitive cloud environment metadata.

The root cause of this vulnerability lies in the behavioral discrepancy between Go's standard library IP classification methods and operating-system level socket routing. Go's net.IP structure provides classification functions such as IsLoopback(), IsPrivate(), and IsLinkLocalUnicast(). While Go natively decodes IPv4-mapped IPv6 formats (such as ::ffff:a.b.c.d) back to their 4-byte standard equivalent during To4() conversion, it does not apply this normalization to other transition mechanisms.

Several active transition protocols encapsulate 32-bit IPv4 targets inside 128-bit IPv6 envelopes. These protocols include NAT64 Well-Known Prefixes (WKP) defined in RFC 6052 (64:ff9b::/96), 6to4 Tunneling defined in RFC 3056 (2002::/16), Teredo Tunneling defined in RFC 4380 (2001:0000::/32), and legacy IPv4-compatible addresses specified in RFC 4291 (::/96). When an address matching one of these blocks is evaluated by net.IP.IsPrivate(), the function inspects only the outer structural prefix and classifies the address as a global, routable IPv6 address.

Despite passing the application-layer validation check as a public peer, the destination IP address undergoes a transformation during connection establishment. When the dual-stack operating system network stack handles the socket routing, it decapsulates the transition wrapper. The underlying network handler routes the outbound traffic to the nested, private, or restricted IPv4 address contained within the trailing 32 bits. This validation-to-routing gap permits reliable SSRF exploitation against internal targets.

Prior to version 4.18.0, the checkIP function in pkg/request/ssrf.go directly validated resolved IP addresses without structural sanitization. The implementation failed to parse the nested IPv4 addresses hidden inside transition envelopes, meaning any encapsulation bypassing standard To4() evaluation succeeded.

To resolve this flaw, a normalization helper named effectiveIP was introduced. This function intercepts the validation loop, extracts encapsulated IPv4 addresses from transition headers, and converts them to standard 4-byte structures before passing them to range classification functions. The patch introduces the following validation and normalization routines:

// pkg/request/ssrf.go
 
var nat64WellKnownPrefix = []byte{
	0x00, 0x64, 0xff, 0x9b,
	0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00,
}
 
var teredoPrefix = []byte{0x20, 0x01, 0x00, 0x00}
 
func effectiveIP(ip net.IP) net.IP {
	if ip == nil {
		return nil
	}
	if v4 := ip.To4(); v4 != nil {
		return v4
	}
	v6 := ip.To16()
	if v6 == nil {
		return ip
	}
 
	// NAT64 well-known prefix
	if bytes.HasPrefix(v6, nat64WellKnownPrefix) {
		return net.IPv4(v6[12], v6[13], v6[14], v6[15]).To4()
	}
 
	// 6to4 2002::/16
	if v6[0] == 0x20 && v6[1] == 0x02 {
		return net.IPv4(v6[2], v6[3], v6[4], v6[5]).To4()
	}
 
	// Teredo client IPv4 is last 4 bytes XOR 0xff
	if bytes.HasPrefix(v6, teredoPrefix) {
		return net.IPv4(v6[12]^0xff, v6[13]^0xff, v6[14]^0xff, v6[15]^0xff).To4()
	}
 
	// IPv4-compatible ::a.b.c.d
	var zero [12]byte
	if bytes.Equal(v6[:12], zero[:]) {
		if last := binary.BigEndian.Uint32(v6[12:16]); last > 1 {
			return net.IPv4(v6[12], v6[13], v6[14], v6[15]).To4()
		}
	}
	return ip
}

This normalization forces Go's standard range checks to operate on the address the packet actually reaches. However, note that while the patch successfully addresses standardized prefixes, custom Network-Specific Prefixes (NSPs) deployed locally within an enterprise network will bypass the static nat64WellKnownPrefix pattern. Organizations running custom translation overlays must account for custom boundaries to guarantee comprehensive security.

An attacker with authenticated remote-download privileges can initiate the exploit by interacting with the download task endpoint. The primary insertion vector is the SrcUri parameter inside the API endpoint /api/v3/tasks/download. The application takes the host supplied in this parameter, resolves it to an IP address, validates it against the security checks, and then instructs the HTTP helper to perform a download request.

To construct a bypass targeting loopback (127.0.0.1), the attacker converts the IPv4 octets into hex bytes (7f, 00, 00, 01) and attaches them to the Well-Known NAT64 Prefix (64:ff9b::/96). The resulting IPv6 address is representationally defined as [64:ff9b::7f00:0001]. A sample HTTP payload targeting an internal administration panel on port 8080 is structured as follows:

POST /api/v3/tasks/download HTTP/1.1
Host: your-cloudreve-instance.com
Authorization: Bearer <valid_user_jwt>
Content-Type: application/json
 
{
  "SrcUri": "http://[64:ff9b::7f00:0001]:8080/admin/settings"
}

When the task engine processes this request, the host DNS resolution step yields 64:ff9b::7f00:0001. The unpatched validation utility inspects this as a routine public IPv6 address, approves the task, and schedules the download process. As the connection is established, the server's OS decapsulates the packet payload, routing the session request directly to the local system service running on port 8080.

This vulnerability is classified under CWE-918 (Server-Side Request Forgery) and exhibits a CVSS v3.1 base score of 6.5. Because exploitation requires authenticated access to remote download components, the immediate threat model assumes an attacker who has established a standard user profile or bypassed authorization blocks on front-facing registration portals.

Successful execution of this attack allows adversaries to interact with loopback systems and private local networks. Internal REST APIs, key-value stores like Redis, administrative endpoints, and databases lacking transport layer security (TLS) or robust localized authentication may be queried directly by the Cloudreve process. This allows for data extraction or potential lateral movement across internal subnets.

Additionally, if Cloudreve is hosted inside a cloud provider's network (such as AWS, Google Cloud, or Azure), the attacker can format the SrcUri to target the Instance Metadata Service (IMDS) at IP 169.254.169.254. Under standard configurations, this path yields access to IAM roles, API tokens, configuration details, and dynamic system metrics, which can easily lead to a full platform compromise.

To fully resolve CVE-2026-79913, administrators must upgrade their installations to Cloudreve version 4.18.0 or later. This release integrates the effectiveIP normalization wrapper, validating nested IPs before making connection requests.

If patching cannot be executed immediately, administrators should implement egress firewall controls on the underlying host operating system. Rules should restrict the Cloudreve system process from making outbound connections to IPv6 blocks utilizing NAT64 (64:ff9b::/96), 6to4 (2002::/16), or Teredo (2001:0000::/32) prefixes. These boundaries block transition-based routing attempts entirely.

For systems running in AWS or similar environments, administrators must configure IMDSv2 and adjust the metadata response hop limit to 1. This prevents SSRF queries from traversing the host virtualization container boundaries, minimizing the risk of credential theft.