CVE-2026-79779 in Rclone
Summary
by MITRE • 08/25/2026
rclone versions before v1.75.0 fail to reject transport downgrades in redirect handling, allowing Basic authorization and Cookie headers to be replayed over plaintext HTTP after same-host HTTPS-to-HTTP redirects. An on-path attacker observing the plaintext hop can capture and reuse credentials to perform WebDAV operations with the compromised account's permissions.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/25/2026
The vulnerability identified in rclone versions prior to v1.75.0 represents a critical flaw in how the application handles HTTP transport redirections, specifically concerning protocol downgrades from HTTPS to plaintext HTTP. This issue stems from an improper validation of redirect targets where the client fails to enforce security constraints when following redirects that change the scheme from secure to insecure. In standard web and API interactions, it is a fundamental security principle that credentials should never be transmitted over unencrypted channels once they have been established or used in a secure context. However, rclone’s HTTP client logic did not adequately check whether the redirect destination maintained the same level of encryption as the initial request. Consequently, when a server responded to an HTTPS request with a redirect status code pointing to an HTTP URL on the same host, rclone would automatically follow this redirect and transmit sensitive headers without re-evaluating the security context of the new endpoint.
The technical flaw centers on the handling of authorization credentials during these redirects. Specifically, Basic Authorization headers containing base64-encoded username and password combinations, as well as Cookie headers that may contain session tokens or authentication identifiers, were included in subsequent requests even after the protocol switched to HTTP. This behavior violates best practices for secure transport management, where any transition from a protected channel to an unprotected one should result in the stripping of sensitive credentials or the termination of the connection attempt. By allowing these headers to be replayed over plaintext, rclone effectively bypasses the confidentiality protections provided by TLS encryption during the redirected hop. This is particularly dangerous because it assumes that same-host redirects are inherently safe regarding credential exposure, which ignores the reality that network paths can change and become susceptible to interception even within trusted domains if intermediate nodes or proxies are compromised.
The operational impact of this vulnerability is severe for users relying on rclone for data synchronization with WebDAV servers or other HTTP-based storage backends. An attacker positioned on the network path between the client and the server, such as through a man-in-the-middle attack on an unsecured Wi-Fi network or via compromised router infrastructure, can observe the plaintext traffic following the redirect. Since Basic Authentication credentials are merely base64 encoded rather than encrypted, they can be trivially decoded by any observer of the HTTP stream. Similarly, session cookies captured in this manner allow for immediate account takeover without needing to crack passwords. Once an attacker obtains these credentials or tokens, they gain full access to the compromised WebDAV account’s permissions. This enables unauthorized reading, writing, modifying, and deleting of files stored on the remote server, leading to potential data exfiltration, integrity violations, and complete loss of confidentiality for sensitive information managed through rclone.
From a classification perspective, this vulnerability aligns with CWE-319, which describes cleartext transmission of credentials over an insecure channel, as well as CWE-601, URL redirection to untrusted site. The attack vector is consistent with MITRE ATT&CK technique T1557, specifically Adversary-in-the-Middle (AitM), where the attacker intercepts and potentially alters communications between two parties who believe they are directly communicating. Furthermore, it relates to CWE-326 regarding insufficient encryption strength when handling sensitive data during state transitions in network protocols. The failure to reject transport downgrades is a common pitfall in HTTP client implementations that prioritize convenience over strict security policy enforcement during redirect chains.
To mitigate this risk, users must upgrade rclone to version v1.75.0 or later, where the issue has been resolved by implementing stricter checks on protocol changes during redirects. In environments where upgrading may not be immediately feasible, administrators should configure their WebDAV servers and reverse proxies to avoid issuing HTTP-to-HTTPS redirect loops that could trigger this behavior, although relying solely on server-side configuration is less robust than fixing the client logic. Additionally, enforcing strict HTTPS policies via HSTS headers can help prevent browsers and clients from downgrading connections in some contexts, though direct API calls like those made by rclone may bypass browser-level protections. It is also advisable to audit existing logs for any signs of credential interception if this vulnerability was present in production environments prior to the patch deployment.