RustFS Flaw Let Low-Privileged Users Steal Objects Across Tenant Boundaries

A low-privileged RustFS user with no read access to a victim bucket could silently exfiltrate its contents by initiating a multipart copy into an attacker-controlled upload and then completing it. The technique required no memory corruption, no exploit chain: just a missing authorization check in the UploadPartCopy code path that every pre-alpha.90 version of RustFS carried.

The U.S. National Vulnerability Database catalogued the flaw as CVE-2026-39360 on April 7, classifying it under CWE-862 (missing authorization). In multi-tenant or shared-hosting RustFS deployments, the bug collapsed tenant isolation entirely: an attacker who could create and complete multipart uploads was free to read any object they could reference, regardless of whether they held read permissions for the source bucket.

The attack path worked because UploadPartCopy, the standard S3-compatible operation for copying source object parts into a new multipart upload, did not verify the caller's authorization against that source object. An attacker initiates a multipart upload to a bucket they control, copies parts from the victim bucket using UploadPartCopy, and completes the upload. Object data lands in attacker-controlled storage with no access denial along the way.

RustFS is a distributed object storage system written in Rust, built for S3-compatible workloads. The NVD entry references the project's GitHub advisory and marks the primary impact as confidentiality loss. Importantly, this is not a memory safety failure: Rust's ownership model offers no protection against authorization logic that simply never checks permissions in the right place. The fix shipped in alpha.90.

Any RustFS instance running a version prior to alpha.90 should be treated as compromised until proven otherwise, particularly in multi-user or managed-hosting environments. Upgrading to alpha.90 is the immediate step, followed by auditing all multipart upload and copy code paths for authorization gaps. Log review is equally critical: search for unusual UploadPartCopy activity during the vulnerable window and cross-reference against known-good access patterns. If that review surfaces evidence of completed unauthorized copies, rotating access keys and re-issuing credentials is the appropriate response.

The NVD publication makes remediation operationally tractable: enterprise vulnerability scanners and SOC tooling can now flag vulnerable RustFS versions by CVE identifier in asset inventories.

Authorization logic bugs like this one are notoriously resistant to automated detection. Static analysis and fuzzing catch memory errors and input validation failures reliably; they struggle with call-flow assumptions and access control models that only break when a specific sequence of operations bypasses a check that should have been there. For object storage systems, the blast radius of a missed auth check scales directly with how much customer data lives in the deployment, which in managed hosting environments can be substantial. The RustFS project's decision to publish a formal advisory and push the fix through NVD means the exposure window is now clearly bounded: pre-alpha.90, and no later.