RustFS Object Lock Bypass: Retained Objects Deletable When Bucket Metadata Unreadable (CVE-2020-73288)

Vulnerability Overview Vulnerability Name: Object Lock (WORM) protections are treated as absent when bucket metadata cannot be read, allowing retained objects to be deleted CVE ID: CVE-2020-73288 Description: When parsing the bucket's Object Lock configuration, RustFS handles several real-world scenarios where the accessor reports a error: the bucket genuinely has no Object Lock, the file (metadata file) cannot be read, or the stored configuration cannot be deserialized. Multiple WORM enforcement points treat all these scenarios as "the bucket is unprotected" and permit the operations. When bucket metadata is unreadable, objects protected solely by bucket-level Object Lock can be deleted via standard / calls and background lifecycle cleanup. This includes retention in COMPLIANCE mode, which is designed to prohibit any subject from overriding—neither the root account nor subjects holding the permission. Affected Versions Affected Versions: All versions up to and including 1.0.0-beta.12 Fixed Version: 1.0.0-rc.1 Remediation Remediation Status: Fixed in version 1.0.0-rc.1 via PR #5648. It is recommended to upgrade to 1.0.0-rc.1 or a later version. Workaround Before attempting to restore deleted objects, ensure that the file for each Object Lock-enabled bucket has been recovered and verify that no buckets are lacking enforced retention. Fix Details The fix distinguishes between the various states that the storage layer can accurately determine—configured, confirmed, absent (no persistent metadata readable), and unresolved (read failure or unparsable storage configuration)—rather than flattening them into a single "absent" state. Enforcement points now fail in non-authoritative states, while confirmed absence remains permitted so that buckets without metadata remain functional.

Goal Reached Thanks to every supporter — we hit 100%!

RustFS Object Lock Bypass: Retained Objects Deletable When Bucket Metadata Unreadable (CVE-2020-73288)

More from this source