GHSA-H4MF-4V27-HGGJ: WebDAV Credential Disclosure via Same-Host HTTPS-to-HTTP Redirect in rclone

A high-severity security vulnerability exists within the WebDAV backend of rclone, a popular command-line program used to manage files on cloud storage. The vulnerability allows sensitive credentials, cookies, and authentication headers to be transmitted in cleartext over the network when a target server initiates an HTTPS-to-HTTP protocol downgrade redirect. This exposure presents a substantial threat in environment topologies where network transactions cross untrusted segments or are subjected to local interception.

The attack surface resides within the application's HTTP redirection logic, specifically how the client handles transitions between secure transport layers (HTTPS) and plaintext transport layers (HTTP) on matching hostnames. Because the default behavior of Go's net/http package preserves authentication headers during same-host redirection, rclone failed to verify whether the target protocol scheme had been downgraded to unencrypted HTTP. Consequently, any credentials associated with the session are replayed over plaintext.

This vulnerability is classified under CWE-319 (Cleartext Transmission of Sensitive Information), CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor), and CWE-522 (Insufficiently Protected Credentials). Successful exploitation allows an on-path attacker or a compromised co-located service to intercept cleartext authentication tokens, such as Basic Authentication headers, session cookies, and custom secret keys. Security teams should prioritize patching this vulnerability to mitigate credential exposure risks during automated backup and synchronization routines.

To understand the root cause of this vulnerability, one must analyze the inner workings of Go's net/http client redirection handling. When an HTTP client processes a redirection status code (e.g., 301, 302, 307, 308), the default behavior of http.Client is to evaluate whether the target URL belongs to the same domain as the original request. If the host matches, the client preserves the original session headers, including highly sensitive fields like Authorization and Cookie, to maintain a seamless session.

However, Go's default implementation fails to validate transport scheme transitions during this host check. If an initial secure request is made to https://example.com/data and the server redirects the client to http://example.com/data, the standard library considers this the "same host." It does not prevent the transmission of credentials over the newly established unencrypted channel. The client continues the session, replaying the Authorization headers over plain text, which can be observed by any eavesdropper.

In rclone's WebDAV backend, this standard library behavior was exacerbated by custom redirect handlers defined in lib/rest/rest.go. The helper function PreserveMethodRedirectFn was designed to preserve the HTTP request verb (such as maintaining a PROPFIND request across temporary redirects instead of changing to a GET as the standard Go client does). Prior to the patch, neither the WebDAV client instantiation nor the custom redirection handlers verified if the target scheme transitioned from https to http. This left the backend exposed to protocol downgrade manipulations.

The vulnerability was remediated by introducing strict transport protocol validation within the custom redirection handlers located in lib/rest/rest.go and explicitly applying these handlers to the WebDAV backend client configuration.

In the patch, a new helper function isHTTPSDowngrade was introduced to examine the protocol scheme transition. It checks the history of the HTTP request execution path by analyzing the via slice, which holds previous requests in the redirection chain:

// isHTTPSDowngrade reports whether following the redirect to req would
// move from an https:// URL to a plaintext http:// URL.
func isHTTPSDowngrade(req *http.Request, via []*http.Request) bool {
	if len(via) == 0 {
		return false
	}
	prev := via[len(via)-1]
	return prev.URL.Scheme == "https" && req.URL.Scheme == "http"
}

The custom redirection handlers were updated to invoke this helper function and immediately abort the redirection process by returning a new error type, ErrHTTPSDowngrade, if a downgrade is detected. This prevents the request from being constructed and transmitted over cleartext:

// ErrHTTPSDowngrade is returned by the redirect handlers when a server tries to
// redirect an HTTPS request to a plaintext HTTP URL. Following such a redirect
// would replay any credentials over the network in cleartext, so rclone refuses.
var ErrHTTPSDowngrade = errors.New("refusing to follow HTTPS to HTTP redirect: would send credentials in cleartext")
 
func PreserveMethodRedirectFn(req *http.Request, via []*http.Request) error {
	if len(via) >= 10 {
		return errors.New("stopped after 10 redirects")
	}
	if isHTTPSDowngrade(req, via) {
		return ErrHTTPSDowngrade
	}
	if len(via) > 0 {
		req.Method = via[0].Method
	}
	return nil
}

To ensure all standard requests outside of method preservation routines are also protected, the patch introduced RefuseHTTPSDowngradeRedirectFn and assigned it to the standard WebDAV HTTP client's CheckRedirect property within backend/webdav/webdav.go:

	// Refuse redirects that downgrade HTTPS to plaintext HTTP.
	client.CheckRedirect = rest.RefuseHTTPSDowngradeRedirectFn
	f.srv = rest.NewClient(client).SetRoot(u.String())

This defensive engineering approach ensures that the application will throw a hard error and fail-closed rather than allowing the Go runtime to transmit credentials insecurely.

Exploitation of this vulnerability requires an Adversary-in-the-Middle (MitM) position, a compromised routing path, or control over DNS resolution for the target server's domain. In a real-world scenario, an attacker can exploit this behavior to harvest WebDAV credentials during automated cloud sync tasks.

An attacker begins by positioning themselves along the network path between the client running rclone and the WebDAV storage gateway. Alternatively, if the target network utilizes insecure DNS configurations, the attacker can execute a DNS hijacking attack to point the initial request to an attacker-controlled gateway. When the rclone client initiates its connection to https://webdav.internal.corp/, the attacker-controlled gateway intercepts the traffic.

While the attacker cannot easily forge a valid SSL/TLS certificate to decrypt the active HTTPS session, they can leverage co-located unsecured services or issue a direct redirection response. By sending a 302 Found response with a Location: http://webdav.internal.corp/ header, they instruct the client to follow the redirect on the same host but over plaintext HTTP.

Because the host name matches, the vulnerable version of rclone automatically packages the Authorization: Basic header into the new plaintext request. The client transmits this request to the unencrypted port, allowing the attacker to capture the unencrypted packets via standard packet-sniffing techniques and extract the base64-encoded credentials. This process requires zero interaction from the system administrator.

The security impact of credential exposure in rclone's WebDAV backend is high. Because WebDAV interfaces are frequently used for automated backups, system synchronization, and corporate shared drives, the credentials transmitted often possess read and write access to highly sensitive directories.

If an attacker successfully retrieves these credentials, they gain unauthorized access to the WebDAV server with the same permissions as the compromised client. This can result in unauthorized data exfiltration, deletion, or modification of critical backups. In enterprise settings, these credentials might also be linked to active directory accounts or single sign-on systems, allowing the attacker to move laterally across internal networks.

The CVSS v3.1 score is evaluated at 7.4 (High), with the vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N. The complexity is high because the attacker must achieve an on-path position or control routing to intercept the downgrade path. However, because no authentication or user interaction is required to trigger the redirect response, the attack is highly reliable once the network position is established.

To fully remediate this vulnerability, security administrators must upgrade all installations of rclone to version v1.75.0 or higher. The upgraded versions contain the mandatory scheme checks that prevent the transmission of credentials during protocol downgrades.

If immediate software upgrades are not possible, administrators should review their WebDAV configurations. The auth_redirect advanced flag must be set to false. When auth_redirect is enabled, it acts as an explicit override that allows rclone to follow redirects that would otherwise be blocked. Ensuring this flag remains disabled is critical for maintaining transport layer security.

From a defensive development perspective, this vulnerability highlights the importance of implementing custom redirection verification rules in Go applications that handle sensitive authorization data. Developers should never rely solely on standard library hostname matching for authentication persistence without explicitly verifying that the transport protocol security has not been degraded.