RustFS 事前署名 PUT URL で他のバケットのデータを読み取られるおそれ

The defect is in the s3s crate you pin, not in RustFS's own code.

A party who holds a SigV4 presigned PUT URL for one object can add one unsigned header, x-amz-copy-source, and read any object the signing key can reach, in any bucket. The copy runs as the signer. I proved the cross-bucket case with a read-back.

A presigned PUT URL carries X-Amz-SignedHeaders=host and signs only that header. s3s collects the headers the client-supplied list names and never walks the headers that arrived, so an x-amz-* header outside the list is never seen. A PUT carrying x-amz-copy-source is a CopyObject, not an upload. A write grant becomes a read. AWS S3 refuses the same request with HTTP 403 and AccessDenied, measured in my own AWS account on 2026-09-01.

PR #6894 did not close GHSA-g8w9-qw9q-fghr

rustfs/rustfs#6894 merged 2026-08-30, and the commit that closed the advisory issue, 01dc55ee, edits one documentation file and no .rs file. I re-measured 1.0.0-rc.5 on 2026-09-04, after it merged. All three headers that advisory names still ride a presigned PUT: x-amz-tagging and x-amz-website-redirect-location return HTTP 200, and x-amz-storage-class returns HTTP 400 InvalidStorageClass with GLACIER, so the server parsed it. The advisory names neither x-amz-copy-source nor reading another object.

Reproduction

Measured on rustfs/rustfs:1.0.0-rc.5, revision 40a2470feb567201165a5b809b7598bb4b1f68f5, on 2026-09-04, and on 1.0.0-beta.12, revision `8601…