CVE-2026-116187 in Rcloneinfo

Summary

by MITRE • 10/25/2026

Rclone from v1.68.0 before v1.75.2 contains an authorization bypass vulnerability in serve s3 --auth-proxy that allows authenticated tenants to manipulate other tenants' multipart uploads by referencing their upload IDs. Attackers who learn a victim's bucket, object, and upload ID can inject parts, complete, or abort in-flight uploads and view upload and object metadata across tenants.

Once again VulDB remains the best source for vulnerability data.

Analysis

by VulDB Data Team • 10/25/2026

The vulnerability identified in Rclone versions from 1.68.0 up to but not including 1.75.2 represents a critical authorization bypass within the S3 serving functionality when operating with an authentication proxy configuration. This flaw specifically affects the multi-tenant environment where multiple users or services interact with the same storage backend through distinct identities. The core technical issue lies in how the application validates tenant isolation during multipart upload operations. When a client initiates a multipart upload, Rclone generates a unique identifier known as an upload ID to track the various parts being uploaded for that specific object. However, due to insufficient validation logic within the serve s3 --auth-proxy module, the system fails to strictly bind these upload IDs to the authenticated tenant who initiated them. Instead of verifying that the requestor has ownership or explicit permission over a given upload ID before processing subsequent actions on it, the application accepts requests based solely on valid authentication credentials for any tenant in the system. This design oversight effectively neutralizes the intended isolation boundaries between tenants, allowing an attacker to interact with resources belonging to other users if they can discover specific identifiers associated with those resources.

From a technical perspective, this vulnerability enables several malicious actions that compromise both data integrity and confidentiality within the storage infrastructure. An adversary who has obtained knowledge of another tenant's bucket name, object key, and active multipart upload ID can inject arbitrary parts into an ongoing upload stream belonging to the victim. This capability allows for potential data poisoning or corruption of files being assembled by legitimate users. Furthermore, the attacker is not limited to injection; they possess the authority to complete these in-flight uploads, thereby finalizing potentially malicious content under the victim's identity and bucket context. Alternatively, the attacker can abort active multipart uploads, causing denial of service conditions for legitimate operations that rely on large file transfers or incremental updates. Beyond manipulation of upload states, the vulnerability also permits unauthorized access to metadata associated with other tenants' uploads and objects. This exposure reveals sensitive information such as object sizes, creation timestamps, storage classes, and potentially internal identifiers, which can be leveraged for further reconnaissance or targeted attacks against specific infrastructure components.

The operational impact of this flaw is severe in environments where Rclone serves S3-compatible APIs to multiple independent tenants. In a multi-tenant architecture, trust boundaries are paramount; the assumption that one tenant cannot interfere with another's data operations must hold true at all times. By allowing cross-tenant manipulation of multipart uploads and metadata viewing, the vulnerability undermines these fundamental security guarantees. Attackers can disrupt business continuity by aborting critical file transfers or corrupting shared datasets through injected parts. The ability to view upload and object metadata across tenants also violates privacy expectations and may expose proprietary information about data handling practices, storage volumes, or active projects of competing organizations sharing the same infrastructure. This level of access effectively grants an authenticated user administrative-like control over other users' partial operations without requiring elevated privileges for those specific resources, creating a significant risk vector in shared cloud storage deployments.

To mitigate this vulnerability, immediate action is required to upgrade Rclone installations that utilize the serve s3 --auth-proxy feature to version 1.75.2 or later, where these authorization checks have been corrected to properly enforce tenant isolation on upload IDs. For organizations unable to patch immediately due to operational constraints, implementing strict network-level access controls and web application firewalls can help restrict exposure by limiting which IP addresses or subnets are allowed to interact with the S3 serving endpoint. Additionally, auditing logs for unusual patterns of multipart upload activity across different tenants may aid in detecting exploitation attempts before significant damage occurs. It is also advisable to review IAM policies and proxy configurations to ensure that least privilege principles are strictly applied, minimizing the blast radius if a credential compromise does occur. Long-term remediation should involve adopting more robust identity federation mechanisms or dedicated S3-compatible storage solutions with proven multi-tenant isolation architectures rather than relying on general-purpose tools configured for complex access control scenarios without rigorous validation layers.

This vulnerability aligns with CWE-269, which describes Improper Privilege Management, as the system fails to enforce proper authorization levels relative to specific resources like upload IDs. It also maps to MITRE ATT&CK technique T1078, Valid Accounts, since exploitation relies on legitimate authentication credentials being used to perform unauthorized actions against other tenants' data. The ability to manipulate multipart uploads further relates to CWE-94, Improper Control of Generation of Code (Code Injection), in the context of injecting malicious parts into a file assembly process, and CWE-200, Exposure of Sensitive Information to an Unauthorized Actor, regarding the unauthorized viewing of metadata across tenant boundaries. Understanding these classifications helps security teams prioritize remediation efforts based on established industry standards for vulnerability management and risk assessment frameworks.

Responsible

VulnCheck

Reservation

10/25/2026

Disclosure

10/25/2026

Moderation

accepted

EPSS

0.00000

KEV

no

Activities

very low

Sources

Do you want to use VulDB in your project?

Use the official API to access entries easily!