GHSA-gx4c-2hqx-cw2r: Cleartext Transmission of Sensitive AWS STS Tokens in rclone S3 Backend via Scheme Downgrade Redirects

The rclone S3 backend utilizes temporary security credentials, such as AWS Security Token Service (STS) session tokens, to authenticate requests securely. These credentials are transmitted via the X-Amz-Security-Token HTTP header to prove the caller's identity and permissions. To prevent credential leakage, the application contains redirection checking logic that strips sensitive headers if the HTTP redirection chain crosses host boundaries.

However, a design flaw exists in the redirection logic implemented in version 1.74.3. The security checker does not validate the URI scheme (HTTPS versus HTTP) during evaluation. If an initial secure connection to an S3 endpoint is redirected to an unencrypted endpoint on the same host, the application classifies the destination as the same host and follows the redirect without stripping the authorization headers.

As a consequence of this logic failure, the sensitive security token is transmitted over unencrypted HTTP. An attacker positioned on the local network or adjacent routing path can capture this traffic to extract the valid STS token. Once obtained, the attacker can leverage the credentials to perform operations against the backend S3 storage within the validity window of the token.

The root cause of this vulnerability lies in the implementation of the s3RedirectCrossesHost function within the backend/s3/s3.go source file. This helper function is registered in the S3 client configuration to determine whether an HTTP redirect has traversed to an external, untrusted boundary.

In vulnerable versions of the application, the verification logic relies exclusively on the Host field of the parsed Golang url.URL struct. The Host property only represents the hostname and optionally the port (e.g., bucket.example.com). It does not contain the protocol scheme of the resource identifier.

When a server responds to an HTTPS request with an HTTP redirect on the same hostname, the logic compares the original via[0].URL.Host value with the new target req.URL.Host value. Because both strings match, the function incorrectly returns false. This prevents the client from invoking header-stripping protocols, resulting in cleartext transmission of the X-Amz-Security-Token header.

Below is the vulnerable implementation of s3RedirectCrossesHost found in backend/s3/s3.go:

func s3RedirectCrossesHost(req *http.Request, via []*http.Request) bool {
	if len(via) == 0 {
		return false
	}
	host := via[0].URL.Host
	for _, redirect := range via[1:] {
		if redirect.URL.Host != host {
			return true
		}
	}
	return host != req.URL.Host
}

The implementation evaluates the redirect chain sequentially, but only verifies that redirect.URL.Host matches the original host. It ignores changes in URL.Scheme (e.g. from https to http).

The patched version introduces strict scheme tracking, as seen in the code change below:

func s3RedirectCrossesHost(req *http.Request, via []*http.Request) bool {
	if len(via) == 0 {
		return false
	}
	scheme, host := via[0].URL.Scheme, via[0].URL.Host
	for _, redirect := range via[1:] {
		if redirect.URL.Host != host || redirect.URL.Scheme != scheme {
			return true
		}
	}
	return host != req.URL.Host || scheme != req.URL.Scheme
}

In the patched logic, both Scheme and Host are tracked from the initial request (via[0]). If either property diverges during the redirect chain, the function evaluates to true, instructing the caller to strip the sensitive headers prior to issuing the subsequent redirect request.

To execute this attack, an adversary must be positioned on an adjacent network or possess the ability to influence routing paths between the rclone client and the S3 target. The attack scenario unfolds as follows:

First, the victim executes an rclone operation against an S3 destination using temporary credentials. If the remote service is misconfigured or a load balancer directs traffic to an unencrypted backend, a redirect response is issued. Alternatively, an attacker on the adjacent network can perform local spoofing (e.g., ARP spoofing or DNS spoofing) to intercept the connection and generate an artificial redirect from port 443 to port 80 on the same host.

When rclone processes the redirect, s3RedirectCrossesHost returns false due to the matching hostnames. The client then sends the follow-up request to the unencrypted HTTP endpoint, carrying the plaintext token. The adjacent network attacker captures the packet stream, extracts the X-Amz-Security-Token, and uses it to access protected S3 resources.

The impact of this vulnerability is limited to environments utilizing temporary S3 credentials, such as AWS STS tokens or similar session token structures. Long-term AWS master access keys, which are handled through different authentication signing mechanisms, are not directly affected by this redirect failure.

The CVSS score is evaluated at 3.1 (Low severity) due to the high barrier to entry. The attacker must possess adjacent network access (AV:A) and the complexity is High (AC:H) because it requires either a backend configuration failure or active network-level poisoning. There is no impact on integrity or availability, as the attack primarily results in confidential credential exposure.

Currently, this vulnerability is not listed on the CISA KEV list, and there are no known public exploits, weaponized execution paths, or reports of active exploitation in the wild.

The primary resolution is upgrading rclone to version 1.74.4 or later, which fully implements the updated s3RedirectCrossesHost checker to strip credentials on scheme downgrades. This represents the only complete remediation for the codebase.

In environments where upgrading the binary is delayed, several infrastructural workarounds should be applied. First, S3 endpoints and reverse proxies must be configured to deny unencrypted HTTP traffic entirely on port 80. This prevents the server from issuing a protocol downgrade redirection.

Additionally, deploying HTTP Strict Transport Security (HSTS) on the network gateway forces clients to automatically rewrite any unencrypted HTTP requests to secure HTTPS before transmission, neutralizing the protocol downgrade entirely.