GHSA-8MXV-9XHP-86H4: Information Disclosure and Credential Leakage during S3 HTTP Redirects in rclone

The S3 backend component in rclone is responsible for orchestrating file transfers, access queries, and endpoint communications with Amazon Simple Storage Service (S3) and compliant object storage platforms. As object storage architectures scale dynamically, S3 endpoints frequently utilize HTTP redirection messages (such as 301, 302, 307, or 308 response codes) to direct clients to specific regional endpoints, caching layers, or partition nodes. Because of these redirects, rclone maintains a custom redirect evaluation module to control the behavior of subsequent connections.\n\nA critical security vulnerability exists in the redirect logic of rclone versions prior to 1.75.0. When following redirects, rclone's handler fails to thoroughly cleanse sensitive headers before dispatching the subsequent request. This leads to information disclosure where critical cloud credentials, session identifiers, and cryptographic keys are transmitted either over plaintext channels or exposed directly to unauthorized target hosts. This vulnerability is classified under CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor).\n\nThe attack surface is exposed whenever rclone is configured to interface with an S3-compatible service that issues redirection payloads, or when an adversary is positioned to influence the transport routing of the active session. This technical analysis provides an exhaustive breakdown of the root cause, execution mechanics, patch structure, and defensive recommendations.

The fundamental cause of the vulnerability lies in the default handling of HTTP redirection within the Go standard library's net/http client, combined with an incomplete sanitization blocklist within rclone's custom redirect handler. Go's standard library implements an automated security measure that strips the conventional Authorization header during cross-host redirects. However, this library mechanism possesses two critical operational gaps that leave custom and protocol-specific variables exposed.\n\nFirst, Go's default redirect policy does not strip the Authorization header when a redirect preserves the exact hostname but downgrades the transport scheme from HTTPS to HTTP. In this scenario, the standard library assumes the administrative domain remains uniform and retains the bearer token, allowing it to be transmitted unencrypted. Consequently, if a service like IBM Cloud Object Storage uses standard Authorization: Bearer <token> headers, these tokens are sent in plaintext during a scheme downgrade.\n\nSecond, modern S3 integrations rely heavily on custom HTTP headers to pass ephemeral credentials, session states, and customer-provided encryption keys. Since Go's net/http package treats custom headers as generic transport metadata, it propagates them across host boundaries unconditionally. Because rclone's original s3CheckRedirect implementation only targeted the single AWS STS header X-Amz-Security-Token for removal, all other critical headers were forwarded to any third-party domain specified in the redirect response.

Analyzing the vulnerable code path in rclone's S3 backend reveals the limited safety measures in place before the fix. The function s3CheckRedirect in backend/s3/s3.go handled the verification of redirections using the following block:\n\ngo\nfunc s3CheckRedirect(req *http.Request, via []*http.Request) error {\n\tif len(via) >= 10 {\n\t return errors.New(\"stopped after 10 redirects\")\n\t}\n\tif s3RedirectCrossesHost(req, via) {\n\t req.Header.Del(\"X-Amz-Security-Token\")\n\t}\n\treturn nil\n}\n\n\nThis function fails on multiple fronts. First, it makes no effort to evaluate protocol transitions, allowing HTTPS-to-HTTP transport scheme downgrades without restriction. Second, by calling req.Header.Del("X-Amz-Security-Token") exclusively, it allows every other custom S3 and IAM header to remain in the request structure as it transfers to the new host.\n\nTo address this, the maintainers implemented patch 9328763d1b73db71e97c0332b19e3747abeb9191 and subsequent patch 7543a7a87884aca957590b20b0714078d51af87b. The modified codebase establishes an explicit blocklist of sensitive headers (s3RedirectSecretHeaders) and enforces a strict protocol downgrade block:\n\ngo\n// s3RedirectSecretHeaders are the request headers carrying origin-bound\n// secrets that must not be forwarded when a redirect crosses a host or\n// downgrades the scheme.\nvar s3RedirectSecretHeaders = []string{\n\t\"X-Amz-Security-Token\", // AWS STS session token\n\t\"X-Amz-S3session-Token\", // S3 Express session token\n\t\"Authorization\", // IBM IAM bearer token\n\t\"ibm-service-instance-id\",\n\t\"X-Amz-Server-Side-Encryption-Customer-Algorithm\",\n\t\"X-Amz-Server-Side-Encryption-Customer-Key\",\n\t\"X-Amz-Server-Side-Encryption-Customer-Key-Md5\",\n\t\"X-Amz-Copy-Source-Server-Side-Encryption-Customer-Algorithm\",\n\t\"X-Amz-Copy-Source-Server-Side-Encryption-Customer-Key\",\n\t\"X-Amz-Copy-Source-Server-Side-Encryption-Customer-Key-Md5\",\n\t\"Referer\", // May contain a presigned URL with cryptographic signatures\n}\n\n\nWith the secret header collection defined, the updated s3CheckRedirect routine performs systematic verification:\n\ngo\nfunc s3CheckRedirect(req *http.Request, via []*http.Request) error {\n\tif len(via) >= 10 {\n\t return errors.New(\"stopped after 10 redirects\")\n\t}\n\t// Never follow a redirect that downgrades the transport from HTTPS to HTTP.\n\tif via[len(via)-1].URL.Scheme == \"https\" && req.URL.Scheme == \"http\" {\n\t return fmt.Errorf(\"refusing to follow insecure redirect from HTTPS to HTTP: %s\", req.URL.Redacted())\n\t}\n\tif s3RedirectCrossesHost(req, via) {\n\t for _, header := range s3RedirectSecretHeaders {\n\t req.Header.Del(header)\n\t }\n\t}\n\treturn nil\n}\n\n\nThis multi-stage control guarantees that transport-level downgrades trigger an immediate failure, while cross-host redirections systematically strip all recognized authentication, token, reference, and cryptographic key variables.

To conceptualize the exploitation vector, consider a scenario involving an Adversary-in-the-Middle (AiTM) positioned on an adjacent network or an untrusted transit path. The target system executes an automated backup task utilizing rclone and an S3-compatible backend such as IBM Cloud Object Storage. The rclone command is initiated with credentials that map to an active IBM IAM bearer token. Below is the workflow mapping the forced protocol downgrade:\n\nmermaid\nsequenceDiagram\n\tautonumber\n\tactor Client as rclone Client\n\tparticipant Attacker as On-Path Attacker\n\tparticipant S3 as S3 Endpoint\n\tClient->>Attacker: HTTPS Connection Request\n\tAttacker->>S3: Relayed HTTPS Request\n\tS3->>Attacker: 302 Redirect to same host (HTTP scheme)\n\tAttacker->>Client: Relayed Redirect (http://s3.ibm.com/path)\n\tClient->>Attacker: Plaintext HTTP Request with Authorization Header\n\tNote over Attacker: Attacker captures plain-text IBM IAM token\n\n\nBecause the host remains unchanged, the client proceeds to transmit the original request over unencrypted HTTP. The on-path attacker captures the plaintext headers, extracting the highly privileged IAM token.\n\nIn a second scenario, an attacker controls or compromises a downstream S3-compatible service. The client utilizes Server-Side Encryption with Customer-Provided Keys (SSE-C) to perform secure read or write actions. Upon receiving the initial request, the compromised endpoint responds with a 307 Temporary Redirect pointing to a malicious, attacker-controlled domain. Rclone processes this redirection, stripping X-Amz-Security-Token but preserving the X-Amz-Server-Side-Encryption-Customer-Key header, delivering the raw decryption keys directly to the attacker.

The exposure of authorization tokens and encryption keys represents a high-severity confidentiality threat. An attacker who successfully intercepts an IBM IAM bearer token gains access to the associated cloud environment with the privileges of the victim's service account. This access allows unauthorized read, write, or deletion operations depending on the bucket policies.\n\nFor S3 Express (directory buckets), the exposure of the X-Amz-S3session-Token allows the attacker to authenticate directly to directory buckets within the active session window. Furthermore, the leakage of SSE-C keys compromises the confidentiality of stored data. If an attacker possesses both the ciphertext and the raw customer-provided key, they can decrypt the target object without authorization.\n\nThe CVSS 3.1 rating is calculated as 5.3 (Medium) with the vector CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N. While the impact on confidentiality is high, the complexity associated with routing manipulation or on-path interception reduces the likelihood of random, broad-spectrum exploitation.

The definitive mitigation for GHSA-8MXV-9XHP-86H4 is upgrading rclone installations to version 1.75.0 or later. This release enforces the secure protocol validation block and fully cleanses the expanded blocklist of secret headers. It is critical to audit and update automated orchestration platforms, container environments, and system processes executing rclone commands.\n\nIn scenarios where immediate software package deployment is constrained by change management policies, organizations must implement defensive configurations to reduce the attack surface. Egress firewall policies should be constructed on host machines to block outbound TCP port 80 (HTTP) traffic generated by the rclone binary, forcing the client to only maintain port 443 (HTTPS) sessions. Furthermore, administrators must verify that S3 backend endpoint configurations are explicitly hardcoded to use https:// schemas inside the rclone.conf config file.\n\n> [!NOTE]\n> Following the deployment of patched rclone binaries, security teams should assume any potentially exposed credentials are compromised and initiate a comprehensive key and token rotation cycle. This includes rotating active IBM Cloud API keys, regenerating S3 access keys, and provisioning new customer keys for SSE-C-enabled datasets.