CVE-2026-39360

Description

RustFS contains a missing authorization check in the multipart copy path (`UploadPartCopy`). A low-privileged user who cannot read objects from a victim bucket can still exfiltrate victim objects by copying them into an attacker-controlled multipart upload and completing the upload. This breaks tenant isolation in multi-user / multi-tenant deployments. ## Impact **Unauthorized cross-bucket / cross-tenant data exfiltration (Confidentiality: High).** An attacker with only minimal permissions on their own bucket (multipart upload + Put/Get on destination objects) can copy and retrieve objects from a victim bucket **without** having `s3:GetObject` (or equivalent) permission on the source. In the attached PoC, the attacker successfully exfiltrates a 5MB private object and proves integrity via matching SHA256 and size. ## Threat Model (Realistic) - **Victim tenant/user** owns a bucket (e.g., `victim-bucket-*`) and stores private objects (e.g., `private/finance_dump.bin`). - **Attacker tenant/user** has **no permissions** on the victim bucket: - cannot `ListObjects`, `HeadObject`, `GetObject`, or `CopyObject` from the victim bucket. - Attacker has **minimal permissions only on attacker bucket**: - `CreateMultipartUpload`, `UploadPart`, `UploadPartCopy`, `CompleteMultipartUpload`, `AbortMultipartUpload`, - and `PutObject`/`GetObject` for objects in attacker bucket. - Despite this, attacker can exfiltrate victim objects via multipart copy. ## Root Cause Analysis The access control layer fails open for multipart copy-related operations: File: `rustfs/src/storage/access.rs` - `abort_multipart_upload()` returns `Ok(())` without authorization (L435–437) - `complete_multipart_upload()` returns `Ok(())` without authorization (L442–444) - `upload_part_copy()` returns `Ok(())` without authorization (L1446–1448) In contrast, `copy_object()` correctly enforces authorization: - source `GetObject` authorization (L469) - destination `PutObject` authorization (L478) The multipart copy implementation reads the source object directly: File: `rustfs/src/app/multipart_usecase.rs` - `store.get_object_reader(&src_bucket, &src_key, ...)` (L959–962) Because `upload_part_copy()` does not enforce source `GetObject` authorization, the server reads and copies victim data even when the requester lacks permission. ## Affected Versions - **Tested vulnerable on:** `main` @ `c1d5106acc3480c275a52344df84633bb6dcd8f0` - **Git describe:** `1.0.0-alpha.86-3-gc1d5106a` The fail-open authorization behavior for `UploadPartCopy` was introduced in: - **Commit:** `09ea11c13` (per `git blame` on `rustfs/src/storage/access.rs:1443-1448`) **Affected range (recommended wording):** - All versions **from** commit `09ea11c13` **through** `c1d5106acc3480c275a52344df84633bb6dcd8f0` (and likely any releases containing those commits) until a fix is applied. ### Package version (Cargo metadata) - `rustfs` crate version in this tree: **0.0.5** (`cargo metadata`) ## Proof of Concept (PoC) – Real Commands + Verified Results ### Files Place the PoC script at the repository root: - **PoC script:** [`poc_uploadpartcopy_exfil_v3.sh`](https://github.com/user-attachments/files/26006935/poc_uploadpartcopy_exfil_v3.sh) - **Captured output:** [`poc_v3_output.txt`](https://github.com/user-attachments/files/26006938/poc_v3_output.txt) - *(Optional)* **Redacted debug log:** `upload_part_copy_debug_redacted.log` (Authorization/signature redacted) ### Environment RustFS running locally (Docker is simplest), listening on: - `http://127.0.0.1:9000` Tools: - `awscli`, `jq`, `awscurl` ### Steps to Reproduce 1) Start RustFS (example): ```bash docker compose -f docker-compose-simple.yml up -d ```` 2. Run the PoC and save output: ```bash chmod +x poc_uploadpartcopy_exfil_v3.sh ./poc_uploadpartcopy_exfil_v3.sh | tee poc_v3_output.txt ``` ### Attachments * [`poc_uploadpartcopy_exfil_v3.sh`](https://github.com/user-attachments/files/26006950/poc_uploadpartcopy_exfil_v3.sh) * [`poc_v3_output.txt`](https://github.com/user-attachments/files/26006953/poc_v3_output.txt) ### Expected Behavior * Attacker operations against victim bucket should be denied: * `ListObjects` -> AccessDenied * `HeadObject` -> AccessDenied * `GetObject` -> AccessDenied * `CopyObject` -> AccessDenied * `UploadPartCopy` from victim -> attacker multipart should also be denied. ### Actual Behavior * All direct operations against victim are denied (as expected), * but **`UploadPartCopy` succeeds**, and attacker retrieves the copied object from attacker bucket. ### Observed PoC Output Victim uploads a private object: * size: `5,242,880` bytes * sha256: `fda018db1da9d8f4c1b287c75943384a3b4ede391ec156039b6d94e17d6ad68f` Attacker exfiltrates it via multipart copy: * stolen size: `5,242,880` bytes * stolen sha256: `fda018db1da9d8f4c1b287c75943384a3b4ede391ec156039b6d94e17d6ad68f` Proof: * hashes and sizes match (victim == stolen) -> unauthorized cross-bucket read confirmed. ## Network Evidence (Redacted) The debug log shows a successful request with: * HTTP method: `PUT` * destination: `/<attacker-bucket>/<dst-key>?partNumber=1&uploadId=...` * header: `x-amz-copy-source: <victim-bucket>/private/finance_dump.bin` * response: `HTTP/1.1 200` with `<CopyPartResult><ETag>...</ETag>...</CopyPartResult>` ## Fix Implement authorization checks equivalent to `copy_object()` for multipart copy paths: * `upload_part_copy`: * enforce **source** `GetObject` authorization on `x-amz-copy-source` * enforce **destination** `PutObject` authorization on the target object * (recommended) apply the same tag-condition enforcement used by `copy_object()` on the source. * `complete_multipart_upload`: * enforce destination `PutObject` authorization * `abort_multipart_upload`: * enforce appropriate multipart permission (or destination `PutObject` as a safe boundary)