CVE-2026-79780 in Rclone
Summary
by MITRE • 08/25/2026
rclone before v1.75.0 fails to sanitize IBM IAM bearer tokens and SSE-C encryption keys during S3 redirect callbacks, allowing credentials to be preserved across scheme or host changes. Attackers observing network traffic from a trusted endpoint can capture reusable IBM IAM tokens on same-host HTTPS-to-HTTP downgrades or SSE-C keys on cross-origin redirects to access protected S3 objects.
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 1.75.0 represents a critical flaw in how the software handles credential sanitization during HTTP redirect operations, specifically affecting integrations with IBM Cloud Object Storage and Amazon S3 compatible services. This issue stems from an insufficient input validation mechanism where sensitive authentication tokens and encryption keys are inadvertently preserved when the client follows redirects that involve changes to the scheme or host. In standard web security practices, credentials should be stripped or restricted during such transitions to prevent leakage across different trust boundaries. However, rclone's implementation failed to enforce these restrictions for IBM IAM bearer tokens and Server-Side Encryption with Customer-Provided Keys (SSE-C) keys when processing redirect responses from storage backends. This oversight creates a scenario where sensitive data intended for secure, authenticated endpoints is exposed during the redirection process, violating fundamental principles of credential isolation and scope limitation.
The technical mechanism behind this vulnerability involves the handling of HTTP redirects, particularly those that trigger scheme downgrades or cross-origin transitions. When rclone encounters an S3 redirect response indicating a move to a different host or protocol, it fails to clear previously stored authentication headers for IBM IAM tokens before initiating the new request. Similarly, SSE-C keys, which are used to encrypt and decrypt objects on the server side using customer-provided encryption keys, are not sanitized during these transitions. This behavior allows an attacker who can observe network traffic from a trusted endpoint within the same host environment to capture reusable IBM IAM bearer tokens if there is a downgrade from HTTPS to HTTP. In cross-origin scenarios involving SSE-C, the encryption key itself may be transmitted in plaintext or captured via side channels, allowing unauthorized parties to decrypt protected objects stored in the bucket. The flaw effectively bypasses the security controls designed to limit credential exposure based on origin and protocol integrity.
The operational impact of this vulnerability is severe, as it enables both passive eavesdropping attacks and potential account takeover scenarios depending on the configuration and network environment. For IBM IAM users, an attacker monitoring local traffic or exploiting a man-in-the-middle position during HTTP downgrades can harvest valid bearer tokens that grant access to cloud resources without requiring further authentication steps. These captured tokens remain valid until their expiration period ends, providing a significant window of opportunity for exploitation. In the context of SSE-C encryption, the exposure of customer-provided keys allows attackers to decrypt sensitive data stored in S3-compatible buckets, leading to direct confidentiality breaches. This is particularly dangerous because SSE-C relies on the assumption that only clients possessing the correct key can access the encrypted objects; compromising this key undermines the entire encryption model and exposes proprietary or regulated data to unauthorized entities.
This vulnerability aligns with CWE-200, which classifies it as an Information Exposure Vulnerability, specifically highlighting the exposure of sensitive information through improper handling during protocol transitions. It also relates to CWE-384, Session Fixation, in contexts where captured tokens can be reused by attackers to impersonate legitimate users. From a threat modeling perspective using the MITRE ATT&CK framework, this flaw facilitates Credential Access techniques such as Network Sniffing (T1040) and potentially Account Manipulation if the stolen credentials are used for lateral movement or privilege escalation within cloud environments. The lack of strict origin checking during redirect handling mirrors issues seen in other web applications where cookies or tokens are leaked to third-party domains, but here it is exacerbated by the specific nature of storage API interactions which often involve complex redirection chains.
To mitigate this risk, organizations running rclone must immediately upgrade to version 1.75.0 or later, where these sanitization checks have been implemented and tested against various redirect scenarios. Until upgrading is possible, administrators should enforce strict HTTPS-only policies for all S3-compatible endpoints to prevent HTTP downgrade attacks that could expose IBM IAM tokens. Additionally, careful review of SSE-C configurations is advised; if cross-origin redirects are unavoidable, consider using server-side encryption with service-managed keys (SSE-S3 or SSE-KMS) instead of customer-provided keys to eliminate the risk of key leakage during redirections. Network segmentation and monitoring should also be enhanced to detect unusual patterns of credential usage or data exfiltration that might indicate exploitation of this vulnerability in environments where upgrading is delayed.