GHSA-W8J7-39HP-8X59: Path Traversal Vulnerability in Cloudreve Remote Downloader Workflow

Cloudreve is an open-source, multi-protocol file management system implemented in Go, which allows users to aggregate multiple storage strategies under a unified interface. A critical component of Cloudreve is its remote download workflow, which integrates with external downloaders like aria2. This integration relies on communication via JSON-RPC to monitor download states and retrieve metadata about completed transfers.

The remote download workflow exposes an attack surface where Cloudreve processes file paths returned directly by the external downloader daemon. The application relies on a validation function, sanitizeFileName, to ensure that filenames received from external systems do not contain dangerous sequences. However, because this function only filters system-specific characters such as colons and backslashes, it fails to neutralize directory traversal structures.

This validation deficiency leads to CWE-22 (Improper Limitation of a Pathname to a Restricted Directory) and CWE-23 (Relative Path Traversal). The impact is limited to users with permissions to configure or execute remote downloads, but it allows for arbitrary file write placement within the virtual URI namespace. This can bypass directory-level boundaries, access control lists, and user-configured storage quota restrictions.

The vulnerability originates in pkg/filemanager/workflows/remote_download.go within the sanitizeFileName function. This function uses Go's strings.NewReplacer to replace invalid characters like backslashes, colons, asterisks, and quotes with underscores. However, it completely omits forward slashes (/) and dots (.), which are the primary building blocks of path traversal strings in Unix-like environments.

When a remote download task completes, Cloudreve queries the downloader daemon using RPC methods to fetch the status of the files. The file metadata returned contains the local path where the downloader saved the file. Cloudreve extracts the filename by trimming the configured download save path from this string. The resulting relative path is then passed directly to sanitizeFileName and subsequently processed.

Because sanitizeFileName leaves traversal sequences untouched, a path containing ../../escaped.txt remains unchanged. The application then passes this string to the URI-joining component of its internal file system implementation. This processing chain allows the untrusted relative path to influence the final physical or virtual storage location.

The resolution of these relative segments occurs inside JoinRaw, which splits the input string by path separators and sequentially applies the directory movements to the base URI. When encountering the .. elements, the URI resolver moves up the directory tree past the intended sandbox base directory. This is the logical core of the vulnerability, where trusted virtual namespace paths are programmatically overridden by the untrusted downloader input.

To understand the vulnerable code path, we must inspect the sanitizeFileName implementation and its application during target path resolution. The following code block shows the vulnerable sanitizer and the two vulnerable assembly points in pkg/filemanager/workflows/remote_download.go:

// Vulnerable sanitizer in pkg/filemanager/workflows/remote_download.go
func sanitizeFileName(name string) string {
    // This replacer lacks rules for forward slashes (/) and dots (.)
    r := strings.NewReplacer("\\", "_", ":", "_", "*", "_", "?", "_", "\"", "_", "<", "_", ">", "_", "|", "_")
    return r.Replace(name)
}

During the download completion process, the master node retrieves the file.Name value from the downloader driver's response payload. It processes this value using the vulnerable sanitizer and then appends it to the destination URI using the vulnerable JoinRaw method:

// Insecure assembly on Master Node (remote_download.go)
sanitizedName := sanitizeFileName(file.Name) // Returns "../../escaped.txt"
dst := dstUri.JoinRaw(sanitizedName)         // Resolves outside the base directory
src := filepath.FromSlash(path.Join(m.state.Status.SavePath, file.Name))

Similarly, slave nodes that process remote downloads construct the transfer entities using the same insecure pattern. They register the uploaded entities with the resolved destination paths, allowing files to bypass target storage directories during clustered node synchronization:

// Insecure assembly on Slave Node (remote_download.go)
dst := dstUri.JoinRaw(sanitizeFileName(f.Name)) // Insecure resolution
src := path.Join(m.state.Status.SavePath, f.Name)
payload.Files = append(payload.Files, SlaveUploadEntity{
    Src:   src,
    Uri:   dst,
})

The JoinRaw function in pkg/filemanager/fs/uri.go splits the argument and routes the individual directory steps directly to the URI's Join method. Because Join resolves parent directories incrementally when it encounters .., the structure is walked back beyond the root of the targeted folder, resulting in out-of-bounds file placement.

Exploitation of this vulnerability requires that an attacker have the privileges necessary to schedule remote download tasks in Cloudreve. This configuration is typically restricted to authenticated users or administrators, depending on the system's access control policy. An attacker can execute the exploit using one of two primary attack vectors.

The first vector involves configuring Cloudreve's remote download agent to point to a malicious JSON-RPC server hosted on an attacker-controlled endpoint. When Cloudreve queries this server for download status updates, the server returns manipulated file paths containing relative traversal sequences. The backend blindly trusts the response and places the files in the traversed path.

The second vector is more direct and does not require modifying the RPC endpoint. An attacker can upload a multi-file torrent or metafile download task where the torrent internal file structure contains relative paths (e.g., ../../escaped.txt). If the legitimate aria2 daemon downloads this torrent, it reports the internal relative file paths back to Cloudreve, which processes them using the vulnerable sanitizeFileName routine.

The expected outcome of successful exploitation is the placement of download payloads into arbitrary directories within the Cloudreve storage provider workspace. While this does not automatically grant operating system-level arbitrary code execution, it allows an attacker to bypass file access boundaries, write malicious scripts into web-accessible folders, or overwrite other users' files within the virtual URI namespace.

This vulnerability has been assigned a CVSS v4.0 score of 5.5 (Medium Severity). The vulnerability's attack vector is Network, and it requires low complexity and no user interaction from other victims. However, it does require authenticated privileges to initiate download tasks, which dampens the severity rating compared to unauthenticated remote code execution bugs.

The primary impact of the flaw is a loss of integrity. An attacker can write files to arbitrary locations in the Cloudreve virtual file system. In multi-user setups, this allows a tenant to write files to folders owned by other users or administrators, exposing private storage spaces to unauthorized additions.

Depending on the configured storage backend, the traversal can have additional side effects. If Cloudreve is configured with local file storage and virtual paths reflect direct disk directories, path traversal could allow writing files to arbitrary paths on the host filesystem. This scenario elevates the severity to potential remote code execution if the attacker can overwrite executable binaries or configuration files.

At the time of this analysis, there are no records of active exploitation in the wild, and the vulnerability is not listed in CISA's Known Exploited Vulnerabilities catalog. The exploit maturity is classified as Proof of Concept, as the technical mechanics are well-documented but require specific environmental conditions to achieve significant malicious impact.

To mitigate this vulnerability, users must restrict remote download scheduling permissions to highly trusted accounts. If possible, disable external downloader integrations (such as aria2) until a robust validation patch is applied to the Cloudreve codebase. Additionally, restrict network access to the aria2 JSON-RPC endpoint to prevent unauthorized configuration modifications.

A complete programmatic fix requires modifying sanitizeFileName in pkg/filemanager/workflows/remote_download.go. The function should be updated to strip path traversal sequences using standard Go library methods like filepath.Clean and strings.ReplaceAll to remove relative directory shifts:

func sanitizeFileName(name string) string {
    r := strings.NewReplacer("\\", "_", ":", "_", "*", "_", "?", "_", "\"", "_", "<", "_", ">", "_", "|", "_")
    name = r.Replace(name)
    name = filepath.Clean(name)
    name = strings.TrimPrefix(name, "..")
    name = strings.ReplaceAll(name, "..", "")
    name = strings.TrimPrefix(name, "/")
    return name
}

Furthermore, the URI-joining workflow must perform boundary checks. When joining a base URI with user-supplied relative path fragments, the application must verify that the resulting URI retains the original base URI as its prefix. If the resolved path escapes the parent directory, the application must abort the operation and return an access violation error.

func SafeJoinRaw(baseUri *URI, elem string) (*URI, error) {
    sanitized := sanitizeFileName(elem)
    dst := baseUri.JoinRaw(sanitized)
    if !strings.HasPrefix(dst.String(), baseUri.String()) {
        return nil, errors.New("path traversal attempt detected")
    }
    return dst, nil
}