Sep 11, 2026·6 min read·41 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) |
A path traversal vulnerability (CWE-22) in Contao CMS allows unauthenticated remote attackers to bypass directory boundary restrictions in ImagesController and access files within the project directory.
Contao Open Source CMS versions 4.0.0 through 5.3.49 and 5.4.0-RC1 through 5.7.11 contain a Cross-Site Request Forgery (CSRF) vulnerability in backend parameter handling. The `RequestTokenListener` component validates anti-CSRF tokens solely for HTTP POST requests, while GET-based declarative guards run only when an `act` parameter is present in the query string. Consequently, custom backend actions dispatched via alternative parameters such as `key=` can execute without CSRF token verification when triggered by an authenticated user.
Contao CMS versions 4.1.0 through 5.3.49 and 5.4.0-RC1 through 5.7.11 fail to validate form submission tokens and enforce rate limiting when processing activation email resend requests via HTTP POST, enabling resource exhaustion and account state enumeration.
An information disclosure vulnerability in Contao CMS allows unauthenticated site visitors to view protected page titles, URLs, and text excerpts through search queries when protected page indexing is disabled after previously being enabled.
In Vikunja prior to version 2.6.0, relation creation via the CalDAV endpoint fails to invoke the TaskRelation.CanCreate authorization check. This missing access control allows an authenticated user to establish unauthorized relationships and perform write operations against any task, provided its unique identifier (UID) is known.
A cross-project information disclosure vulnerability in Vikunja allows authenticated users with read access to one project to view private task details from unauthorized projects via subtask expansion parameters.