Sep 11, 2026·6 min read·19 visits
rclone's dynamic server creation endpoint fails to enforce requested authentication proxies, falling back to unauthenticated anonymous access or exposing root filesystems.
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.
rclone is a command-line utility designed to synchronize, copy, and manage files across various cloud storage backends. To support dynamic configurations, rclone includes a Remote Control (RC) HTTP API that allows remote clients to spawn protocol-specific servers, such as FTP, SFTP, and S3, on demand via the /serve/start endpoint. This interface accepts custom, request-specific authentication proxy options to delegate client validation to external systems.
CVE-2026-88044 identifies a critical security vulnerability within rclone's dynamic server creation mechanisms. The flaw resides in how dynamic server constructors evaluate authentication parameters. Instead of referencing the request-scoped configurations, the server initialization logic mistakenly queries process-global configurations, causing the requested authentication proxy settings to be silently ignored.
The technical impact of this scope mismatch is severe, resulting in complete authentication bypass. For dynamically spawned FTP servers, the system defaults to an anonymous authentication state, permitting read and write access to the underlying storage using any credentials. For S3 and SFTP servers, the vulnerability circumvents tenant-isolation and directory-sandboxing mechanisms, exposing the global root virtual file system.
The core of the vulnerability is an architectural scope-confusion error between the process-global configuration structure (proxy.Opt) and the request-scoped parameter structure (proxyOpt). When a client invokes the /serve/start API endpoint, the HTTP handler maps incoming JSON options to a local proxyOpt pointer. The expectation is that the dynamic server constructor will utilize these request-scoped settings to configure the per-instance authentication proxy.
However, the constructors inside the FTP, S3, and SFTP modules do not inspect the request-scoped proxyOpt.AuthProxy property during initialization. Instead, they evaluate the global proxy.Opt.AuthProxy string. Since the global configuration is empty by default when rclone is started without global command-line flags, the condition evaluates to false, and the server fails to instantiate the requested authentication proxy.
Because the authentication proxy remains uninitialized, the dynamic servers fallback to default, hardcoded behaviors. In the case of FTP, the underlying library interprets the lack of both defined credentials and an active auth-proxy as an instruction to enable anonymous access. The server then allows connection requests containing the username 'anonymous' and an arbitrary password, providing the caller with unauthorized access to the configured storage backend.
To understand the flaw at the implementation level, analyze the pre-patch constructor within cmd/serve/ftp/ftp.go. The vulnerable conditional statement explicitly references the global package-level option structure instead of the local parameter passed by the caller. This results in the initialization of the static global virtual file system rather than the dynamic authentication proxy.
// VULNERABLE CODE - Pre-patch in cmd/serve/ftp/ftp.go
if proxy.Opt.AuthProxy != "" { // Bug: Checks global instead of request-scoped variable
d.proxy = proxy.New(ctx, proxyOpt, vfsOpt)
d.userPass = make(map[string]string, 16)
} else {
d.globalVFS = vfs.New(ctx, f, vfsOpt) // Fallback to unauthenticated global VFS
}The official patch resolved this issue by abstracting the virtual file system (VFS) and proxy handling into a unified proxy.Provider class. The newly introduced proxy.NewProvider constructor correctly receives and evaluates the request-scoped proxyOpt parameter, ensuring that the local options take precedence over the uninitialized global values. This prevents the silent fallback to static file structures when an authentication proxy is explicitly requested.
// PATCHED CODE - Post-patch in cmd/serve/proxy/proxy.go
func NewProvider(ctx context.Context, f fs.Fs, vfsOpt *vfscommon.Options, proxyOpt *Options) *Provider {
p := &Provider{}
if proxyOpt != nil && proxyOpt.AuthProxy != "" { // Correct: Evaluates the local parameter
p.proxy = New(ctx, proxyOpt, vfsOpt)
} else {
p.vfs = vfs.New(ctx, f, vfsOpt)
}
return p
}Exploitation of this vulnerability requires network access to the rclone Remote Control (RC) HTTP API (typically listening on port 5572). An attacker or automated service first identifies an rclone instance and sends a crafted POST request to the /serve/start endpoint. This request attempts to spawn an FTP server while supplying an authentication proxy configuration to make the setup appear secure.
Because of the scope mismatch, the newly spawned FTP server ignores the configured LDAP or HTTP authentication proxy and exposes an anonymous FTP listener. The attacker then connects to the newly opened FTP port using standard client software. When prompted for credentials, the attacker inputs the username 'anonymous' and a blank or arbitrary password, bypassing all authentication challenges.
For S3 and SFTP protocols, the exploitation process is similar. Instead of generating a localized, sandboxed environment for the client, the S3 or SFTP server operates without the authentication middleware. This bypass exposes the root of the remote storage system to any user capable of logging in, removing multi-tenant boundary protections and allowing unauthorized file manipulation.
The impact of CVE-2026-88044 is rated as Critical, with a CVSS v3.1 base score of 9.1. The attack vector is Network, and the attack complexity is Low, meaning any remote actor with access to the dynamic server's listening ports can trigger the vulnerability. No prior privileges or user interactions are required to exploit the authentication bypass.
Successful exploitation grants unauthorized read and write access to the targeted remote storage backends. Attackers can exfiltrate sensitive files, modify existing data, or delete cloud assets. Because rclone acts as a bridge to major cloud providers, the scope of exposure extends beyond the local host to remote AWS S3 buckets, Dropbox directories, or corporate SFTP targets.
While there are no public weaponized exploits or documented instances of this vulnerability being actively exploited in ransomware campaigns, the ease of exploitability makes it a highly attractive target. The vulnerability represents a complete failure of the authorization boundary, meaning trust in dynamic multi-tenant cloud storage gateways running affected versions of rclone is entirely compromised.
The recommended mitigation is to upgrade all rclone installations to version 1.75.1 or later. The patch corrects the constructor evaluations and prevents the unauthenticated fallbacks. Organizations using package managers should verify that their rclone binary contains the security fix introduced in commit 739403963abf6f58003c2becd5f7c4ad0d644153.
If an immediate upgrade is not feasible, operators can apply several defensive workarounds. First, disable the Remote Control API entirely if dynamic server spawning is not required. If the RC API must remain active, ensure that the API listener is bound strictly to 127.0.0.1 and that robust access controls, such as TLS client certificates and strong passwords via the --rc-user and --rc-pass flags, are enforced.
Additionally, operators can mitigate the vulnerability by defining an authentication proxy globally using command-line arguments when starting the rclone process. Because the vulnerability only manifests when the global configuration is blank, setting a dummy or global --auth-proxy value forces the conditional checks to evaluate to true, thereby preventing the insecure fallback state.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N| Product | Affected Versions | Fixed Version |
|---|---|---|
rclone rclone | >= 1.70.0, < 1.75.1 | 1.75.1 |
| Attribute | Detail |
|---|---|
| CWE ID | CWE-863 |
| Attack Vector | Network (AV:N) |
| CVSS v3.1 | 9.1 (Critical) |
| EPSS Score | N/A |
| Impact | Authentication Bypass / Unauthorized Read & Write |
| Exploit Status | None (No public PoC) |
| CISA KEV Status | Not Listed |
The software performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check, allowing attackers to bypass intended security controls.
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.