DeleteObjects writes delete markers at the resolved path of dot-segment keys, bypassing prefix-scoped delete permissions

Summary

On a versioning-enabled bucket, a DeleteObjects (batch delete) request whose keys contain . or .. path segments (for example allowed/../victim/obj, x/q/../y/z, a/./b) writes the delete marker at the path the storage layer resolves the key to, not at the literal key. Authorization is evaluated on the literal key, so a principal whose delete permission is limited to one prefix (for example allowed/*) can hide objects under other prefixes of the same bucket.

This is a variant of the object-key path-traversal class fixed earlier for single-object operations (GHSA-pq29-69jg-9mxc; see also the closed GHSA-8r6f-hmq2-28rg): the batch delete path does not apply the same object-name validation.

Details

• Single-object delete validates the key: handle_delete_object_with_journal_inner calls check_del_obj_args(bucket, object)? (crates/ecstore/src/store/object.rs, around line 4794 on main 3268c42e00), which rejects such names, so DeleteObject returns 400.
• The batch path handle_delete_objects_with_journal_and_accounting_inner (same file, starting around line 5211) encodes each name with encode_dir_object but performs no per-object check_del_obj_args / check_bucket_and_object_names. The app-layer batch delete handler (rustfs/src/app/object/delete.rs) does not validate the keys either.
• Observed behaviour (measured against a debug build of RustFS main at e870a6d25b, served by the current HTTP stack):
  • versioning-enabled bucket: `De…