CVE-2026-39360: 
Rust vulnerability analysis and mitigation

CVE-2026-39360 is a missing authorization vulnerability in RustFS, a distributed object storage system built in Rust, affecting the multipart copy path (UploadPartCopy). A low-privileged authenticated user who lacks read permissions on a victim bucket can bypass access controls to exfiltrate objects by copying them into an attacker-controlled multipart upload. All versions prior to alpha.90 (including alpha.1 through alpha.89) are affected. The vulnerability was published on April 7, 2026, with a CVSS v3.1 score of 4.3 (Medium) and a CVSS v4.0 score of 5.3 (Medium) (GitHub Advisory, RustFS Advisory).

The root cause is a fail-open authorization implementation in rustfs/src/storage/access.rs, classified as CWE-862 (Missing Authorization). Specifically, the functions upload_part_copy() (L1446–1448), complete_multipart_upload() (L442–444), and abort_multipart_upload() (L435–437) all return Ok(()) without performing any authorization check, while the analogous copy_object() function correctly enforces both source GetObject and destination PutObject authorization. Because upload_part_copy() skips the source authorization check, the underlying store.get_object_reader() call in rustfs/src/app/multipart_usecase.rs reads and copies victim data regardless of the requester's permissions. The vulnerability is exploitable over the network by any authenticated low-privileged user with only minimal permissions on their own bucket (GitHub Advisory, RustFS Advisory).

Successful exploitation allows a low-privileged attacker to exfiltrate arbitrary objects from any victim bucket without s3:GetObject (or equivalent) permission on the source, directly breaking tenant isolation in multi-user and multi-tenant deployments. The PoC demonstrates complete exfiltration of a 5 MB private object with SHA256 integrity verification, confirming full unauthorized cross-bucket read. There is no integrity or availability impact; the confidentiality impact is limited to the data stored in victim buckets accessible via the RustFS instance (GitHub Advisory).

A public proof-of-concept exploit script (poc_uploadpartcopy_exfil_v3.sh) is included in the security advisory and provides concrete, step-by-step reproduction instructions against a real RustFS deployment. The EPSS score is approximately 0.034% (0.000380), indicating low current exploitation probability. There is no evidence of in-the-wild exploitation at this time, no known threat actor attribution, and the vulnerability is not listed in the CISA KEV catalog. Qualys has added detection for this vulnerability (detection ID 5010647) (GitHub Advisory, RustFS Advisory).

1. Obtain low-privileged credentials: Acquire credentials for a low-privileged account on the target RustFS instance with only minimal permissions on an attacker-controlled bucket (e.g., CreateMultipartUpload, UploadPart, UploadPartCopy, CompleteMultipartUpload, PutObject, GetObject on attacker bucket only).
2. Identify target object: Determine the victim bucket name and object key to exfiltrate (e.g., victim-bucket/private/finance_dump.bin). Direct operations such as ListObjects, HeadObject, GetObject, and CopyObject against the victim bucket will return AccessDenied.
3. Initiate multipart upload: Using awscli or equivalent S3-compatible tooling, initiate a multipart upload on the attacker-controlled bucket:

   aws s3api create-multipart-upload --bucket attacker-bucket --key stolen-object

4. Execute UploadPartCopy: Issue an UploadPartCopy request specifying the victim object as the copy source via the x-amz-copy-source header:

   aws s3api upload-part-copy --bucket attacker-bucket --key stolen-object \
     --upload-id <UploadId> --part-number 1 \
     --copy-source victim-bucket/private/finance_dump.bin

   The server processes this request without enforcing source GetObject authorization, returning HTTP 200 with an ETag.
5. Complete the multipart upload: Finalize the upload to assemble the copied object in the attacker bucket:

   aws s3api complete-multipart-upload --bucket attacker-bucket --key stolen-object \
     --upload-id <UploadId> --multipart-upload '{"Parts":[{"PartNumber":1,"ETag":"<ETag>"}]}'

6. Retrieve the exfiltrated object: Download the now-assembled object from the attacker bucket and verify integrity via SHA256 hash comparison with the known victim object hash (GitHub Advisory, RustFS Advisory).

• Network: HTTP PUT requests to /<attacker-bucket>/<key>?partNumber=<N>&uploadId=<id> containing the header x-amz-copy-source: /<victim-bucket>/<object-key> from a user who does not have read permissions on the victim bucket; successful HTTP 200 responses to such requests on RustFS instances prior to alpha.90.
• Logs: RustFS access logs showing UploadPartCopy operations (HTTP PUT with partNumber and uploadId query parameters and x-amz-copy-source header) where the source bucket belongs to a different tenant than the authenticated user; absence of corresponding GetObject authorization checks in debug logs for the same source object.
• Logs: Sequences of CreateMultipartUpload → UploadPartCopy (cross-bucket source) → CompleteMultipartUpload → GetObject from the same low-privileged user identity within a short time window.
• File System: Unexpected objects appearing in attacker-controlled buckets that match (by size or hash) objects stored in other tenants' private buckets (GitHub Advisory, RustFS Advisory).

Upgrade RustFS to version alpha.90 or later, which implements proper authorization checks in upload_part_copy(), complete_multipart_upload(), and abort_multipart_upload() equivalent to those enforced by copy_object(). For deployments that cannot immediately upgrade, implement network-level access controls to restrict or block UploadPartCopy operations (HTTP PUT requests with partNumber and uploadId parameters and x-amz-copy-source headers referencing cross-bucket sources). Additionally, review RustFS access logs for unauthorized cross-bucket UploadPartCopy activity to assess potential prior exploitation (GitHub Advisory, RustFS Advisory).

The vulnerability was reported by researcher thesmartshadow and published by RustFS maintainer overtrue on April 7, 2026. The advisory was noted on Bluesky via the CVE tracking account shortly after publication. No significant broader media coverage or notable security researcher commentary beyond the advisory itself has been identified at this time (RustFS Advisory).