CVE-2026-79913 Overview
Cloudreve is a self-hosted file management and sharing system. Versions prior to 4.18.0 contain a server-side request forgery (SSRF) vulnerability [CWE-697] in the ValidateExternalURL guard within pkg/request/ssrf.go. The guard passes resolved addresses to checkIP without decoding NAT64, IPv4-compatible, and 6to4 IPv4-in-IPv6 transition forms. Authenticated users with remote-download access can supply a SrcUri through RemoteDownloadTask.createDownloadTask that wraps a loopback, private, link-local, or cloud metadata IPv4 address inside an IPv6 wrapper. The wrapped address is classified as public and fetched by the server. The issue is fixed in version 4.18.0.
Critical Impact
Authenticated attackers can force the Cloudreve server to fetch internal services and cloud instance metadata endpoints, exposing credentials such as AWS IAM tokens.
Affected Products
- Cloudreve versions prior to 4.18.0
- Self-hosted deployments exposing the remote-download feature to authenticated users
- Cloud-hosted Cloudreve instances running on AWS, Azure, or GCP with instance metadata endpoints reachable
Discovery Timeline
- 2026-09-22 - CVE-2026-79913 published to NVD
- 2026-09-22 - Last updated in NVD database
- Version 4.18.0 - Cloudreve releases patched version implementing effectiveIP normalization
Technical Details for CVE-2026-79913
Vulnerability Analysis
The vulnerability resides in Cloudreve's SSRF protection layer. When a user submits a URL through RemoteDownloadTask.createDownloadTask, ValidateExternalURL resolves the hostname and passes the resulting net.IP to checkIP for classification against loopback, private, link-local, and metadata ranges. Go's standard library only normalizes IPv4-mapped IPv6 addresses (::ffff:a.b.c.d) via net.IP.To4. Other IPv4-in-IPv6 transition forms including NAT64 (64:ff9b::a.b.c.d), IPv4-compatible (::a.b.c.d), and 6to4 (2002:a.b.c.d::/48) are treated as distinct IPv6 addresses and evaluated against IPv6 allowlists that do not cover the embedded IPv4 space.
An attacker embeds a sensitive IPv4 address such as 169.254.169.254 (the cloud metadata endpoint) inside a 6to4 or NAT64 wrapper. The guard classifies the wrapper as a public IPv6 address, permits the request, and the operating system's dual-stack networking transparently forwards the traffic to the embedded IPv4 destination.
Root Cause
The root cause is incomplete comparison logic [CWE-697] between resolved network addresses and blocklist ranges. checkIP relied on net.IP.To4 alone to unwrap IPv4 semantics, missing three transition encodings defined by IETF specifications that operating systems still route to IPv4 destinations.
Attack Vector
Exploitation requires authenticated access with permission to create remote-download tasks. The attacker submits a SrcUri containing a URL with an IPv6 wrapper that embeds an internal or metadata IPv4 address. The server fetches the target and returns the response body to the attacker, enabling internal service reconnaissance and theft of cloud instance credentials.
package request
import (
+ "bytes"
"context"
+ "encoding/binary"
"errors"
"fmt"
"net"
Source: GitHub Commit 1c5cad6 — the patch introduces an effectiveIP function that normalizes NAT64, IPv4-compatible, and 6to4 wrappers before classification.
Detection Methods for CVE-2026-79913
Indicators of Compromise
- Outbound HTTP requests from the Cloudreve server to cloud metadata endpoints such as 169.254.169.254 or metadata.google.internal
- Remote-download task entries containing IPv6 literals in NAT64 (64:ff9b::), IPv4-compatible (::a.b.c.d), or 6to4 (2002::) formats
- Unexpected downloaded files whose contents match IAM credential responses or internal service JSON payloads
Detection Strategies
- Inspect Cloudreve application logs and the RemoteDownloadTask records for SrcUri values containing IPv6 addresses with embedded IPv4 octets
- Correlate egress network flows from the Cloudreve host to RFC1918, loopback, or link-local ranges immediately following authenticated API activity
- Alert on any process on the Cloudreve host resolving or connecting to 169.254.169.254, fd00:ec2::254, or organization-specific metadata endpoints
Monitoring Recommendations
- Enable audit logging on the Cloudreve remote-download API and forward events to a centralized log platform for retrospective hunting
- Deploy egress filtering rules that log and block traffic from application servers to metadata IP ranges regardless of address family
- Review IAM role usage on the underlying cloud instance for anomalous API calls that could indicate credential exfiltration
How to Mitigate CVE-2026-79913
Immediate Actions Required
- Upgrade Cloudreve to version 4.18.0 or later, which introduces the effectiveIP normalization function
- Restrict the remote-download permission to trusted user groups until the upgrade is complete
- Rotate any cloud instance credentials or API tokens that were reachable from the Cloudreve host
Patch Information
The fix is available in Cloudreve 4.18.0. Technical details are documented in GitHub Security Advisory GHSA-jvh5-97xg-v99f and the corresponding commit 1c5cad6. The patch adds an effectiveIP helper that unwraps NAT64, IPv4-compatible, and 6to4 encodings before the address is checked against the SSRF blocklist.
Workarounds
- Block outbound traffic from the Cloudreve host to 169.254.0.0/16, fd00:ec2::/64, and other cloud metadata address ranges at the network layer
- Configure the cloud provider to require IMDSv2 session tokens, preventing SSRF fetches from retrieving credentials via simple GET requests
- Deploy an egress HTTP proxy that enforces destination allowlisting for all Cloudreve remote-download traffic
# AWS IMDSv2 enforcement to reduce SSRF credential theft risk
aws ec2 modify-instance-metadata-options \
--instance-id i-1234567890abcdef0 \
--http-tokens required \
--http-endpoint enabled \
--http-put-response-hop-limit 1
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
