Sep 11, 2026·6 min read·5 visits
Unauthenticated remote attackers can cause request-level denial of service in rclone servers by sending crafted HTTP Range headers targeting virtualized symlinks (.rclonelink).
A request-level denial of service vulnerability exists in rclone versions prior to 1.75.1 when configured with local symlink virtualization (--links) and serving files over HTTP or WebDAV. An unauthenticated remote attacker can trigger a Go runtime slice bounds panic by sending a crafted HTTP Range request with an offset exceeding the path length of the target symlink.
rclone is a command-line utility designed to manage, sync, and stream files across various cloud storage backends and local file systems. When serving files locally through HTTP or WebDAV protocols, rclone exposes web-based endpoints for client interactions. This service is commonly used to mount or share directories dynamically across networks.
A vulnerability exists in the local backend of rclone when the virtualization of symbolic links is enabled. This feature is activated using the --links flag or setting links=true in the backend configuration. When enabled, rclone translates local symbolic links and represents them as virtual files with a .rclonelink suffix containing the path of the link target.
Remote clients can query these virtual files and request partial content using standard HTTP Range headers. If a crafted request specifies a start offset greater than the length of the destination path string, the application fails to validate the boundary conditions. This failure leads to an unhandled runtime exception and immediate request termination.
The root cause of the vulnerability resides in the interaction between rclone's HTTP range decoding library and the local backend's translation handler. The range decoder parses incoming HTTP Range headers and calculates the desired stream limits. This parser does not restrict the starting offset based on the actual size of the targeted virtual resource.
When the range options are forwarded to the local backend, the system invokes the openTranslatedLink function. This function reads the symbolic link destination path and attempts to slice the resulting string dynamically. It utilizes the unchecked starting offset value directly in a standard Go slice operation.
Go's language specifications mandate that string or slice indexing of the form s[low:] triggers an unrecoverable panic if low exceeds the length of the string s. Because the target path string of a symbolic link is typically brief, any offset exceeding a few dozen bytes satisfies this panic condition. This leads to an uncaught runtime error: slice bounds out of range exception.
In vulnerable versions of rclone, the openTranslatedLink method in backend/local/local.go performs slicing without safety assertions. The unchecked offset is passed directly to the string slicer. Below is the vulnerable segment of code:
// Vulnerable Code Path
func (o *Object) openTranslatedLink(offset, limit int64) (lrc io.ReadCloser, err error) {
linkdst, err := o.readLink()
if err != nil {
return nil, err
}
// Direct slicing using unvalidated offset
return readers.NewLimitedReadCloser(io.NopCloser(strings.NewReader(linkdst[offset:])), limit), nil
}The patched implementation introduces validation checks to safely clamp the starting offset before executing the slicing operation. This prevents out-of-bounds access entirely. Below is the corrected implementation:
// Patched Code Path
func (o *Object) openTranslatedLink(offset, limit int64) (lrc io.ReadCloser, err error) {
linkdst, err := o.readLink()
if err != nil {
return nil, err
}
// Clamp offset into range to avoid panic
if offset < 0 {
offset = 0
}
if offset > int64(len(linkdst)) {
offset = int64(len(linkdst))
}
return readers.NewLimitedReadCloser(io.NopCloser(strings.NewReader(linkdst[offset:])), limit), nil
}By clamping the offset to the length of the destination path string, the code guarantees that the index is always valid. In Go, slicing a string at its exact length is legal and returns an empty string. The caller receives a standard EOF representation, ensuring the connection closes gracefully rather than panicking.
Exploiting this vulnerability requires network access to an exposed rclone HTTP or WebDAV server. The server must be serving a local filesystem with the --links flag active. The target directory must contain at least one symbolic link representing a virtual .rclonelink file.
The attacker constructs a standard HTTP GET request targeting the virtual file. This request must include a Range header with a starting byte value that is larger than the destination path string. For example, a header value of bytes=10000- is sufficient to target most short destination paths.
The process flow of the exploitation chain can be visualized as follows:
When the request is processed, the local backend triggers the slice bounds panic. The Go HTTP server recovers from this panic locally, logs the stack trace, and terminates the TCP connection abruptly. While the core rclone process does not crash, the connection is closed without delivering a response, and repeated requests degrade server performance.
The primary security impact of this vulnerability is a request-level Denial of Service. Because the Go runtime isolates HTTP handlers within separate goroutines, an uncaught panic in a connection handler does not terminate the primary parent process. This containment restricts the scope of the denial of service to active and pending connections.
Despite the isolation, an attacker can continuously issue requests to deplete server resources. Each panic generates extensive traceback logs, increases CPU consumption, and exhausts connection pools. Consequently, legitimate clients may experience connection timeouts and a complete loss of service availability.
Due to the nature of Go's memory-safe runtime environment, this vulnerability cannot be leveraged to achieve remote code execution or arbitrary memory corruption. There is also no associated risk of data confidentiality loss or unauthorized file modification. The vulnerability remains categorized strictly as a localized availability issue.
The primary remediation path is upgrading the rclone installation to version 1.75.1 or later. This release incorporates the necessary offset-clamping logic in the local backend file. Administrators should deploy the updated binary to production environments and restart any active file-serving daemons.
If an immediate upgrade is not feasible, administrators can apply a configuration workaround. Disabling the symbolic link feature prevents the local backend from executing the vulnerable code path. This is achieved by removing the --links or -l flags from the startup commands.
Alternatively, organizations can enforce strict firewall controls or network access control lists to limit access to rclone HTTP and WebDAV ports. Restricting these services to trusted internal IP addresses significantly reduces the exposure of the vulnerability. Web application firewalls can also be configured to block anomalous HTTP Range headers.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L| Attribute | Detail |
|---|---|
| CWE ID | CWE-248, CWE-190 |
| Attack Vector | Network (unauthenticated) |
| CVSS v3.1 Score | 5.3 (Medium) |
| Exploit Status | PoC available (regression tests) |
| Impact | Request-level Denial of Service |
| Vulnerable Component | backend/local (openTranslatedLink) |
The FTP server implementation of rclone is vulnerable to a cross-session identity and credential confusion flaw when configured with an authentication proxy. Under specific multi-tenant configurations where multiple distinct sessions authenticate with the same username, a global map caches credentials globally instead of isolating them inside the session context. This allows a concurrent attacker to hijack the active session backend of a victim using the same username.
An authentication bypass vulnerability exists in rclone when dynamically starting FTP, S3, or SFTP servers via the Remote Control (RC) 'serve/start' API. The server constructors incorrectly check the global process configuration rather than request-scoped options, resulting in a silent bypass of the authentication proxy and enabling unauthenticated access.
Prior to version 1.75.1, rclone's S3 server component ('rclone serve s3') contains an authentication bypass vulnerability when configured with '--auth-proxy' but without '--auth-key'. The application validates AWS Signature Version 4 (SigV4) against an empty secret key string, enabling unauthenticated remote attackers to access storage backends.
rclone versions from 1.49.0 up to 1.75.1 are vulnerable to information disclosure and credential leakage. When configuring custom headers on HTTP connections, rclone fails to strip those headers when following HTTP redirects to external untrusted domains. Additionally, rclone does not prevent scheme downgrades from HTTPS to HTTP on same-host redirects, allowing sensitive standard credentials to be transmitted in cleartext.
A critical path traversal vulnerability (commonly known as 'Zip Slip') exists in rclone's ZIP archive backend implementation (backend/archive/zip/zip.go) between versions 1.72.0 and 1.75.1. The flaw allows an attacker to write arbitrary files outside the designated extraction directory by supplying a maliciously crafted ZIP archive. Additionally, the backend's directory boundary verification routine failed to enforce strict path limits, causing sibling folders sharing a name prefix to match incorrectly and leading to unauthorized data exposure. This issue has been fully resolved in version 1.75.1.
An architectural parser-differential vulnerability in Traefik's routing engine allows unauthenticated attackers to bypass path-based routing rules, authentication middleware, and access logs. The issue stems from inconsistencies in handling rootless/opaque request targets between Go's standard net/http parser and Traefik's internal routing and sanitization layers. This vulnerability compromises the authorization boundary of upstream microservices.