CVE-2026-73288: RustFS Privilege Escalation Vulnerability

CVE-2026-73288 Overview

CVE-2026-73288 is a security constraint bypass in RustFS, a distributed object storage system written in Rust. Versions prior to 1.0.0-rc.1 mishandle Object Lock enforcement in crates/ecstore/src/bucket/object_lock/objectlock_sys.rs. When the enforcement layer encounters a ConfigNotFound result, unreadable .metadata.bin data, or unparseable metadata, it silently treats the bucket as having no lock configuration. Callers such as check_object_lock_for_deletion, delete_prefix, lifecycle expiration, and scanner sweeps then proceed as if retention did not apply. Objects placed under COMPLIANCE retention, which S3 semantics guarantee cannot be deleted before expiration, can therefore be removed or expired.

Critical Impact
Authenticated callers can delete or expire immutable objects that COMPLIANCE-mode Object Lock is supposed to preserve, breaking WORM and regulatory retention guarantees.

Affected Products

RustFS distributed object storage, all versions prior to 1.0.0-rc.1
Deployments relying on RustFS Object Lock for COMPLIANCE-mode retention
Buckets subject to lifecycle expiration or scanner-driven sweeps in vulnerable RustFS builds

Discovery Timeline

2026-08-12 - CVE-2026-73288 published to NVD
2026-08-12 - Last updated in NVD database

Technical Details for CVE-2026-73288

Vulnerability Analysis

RustFS Object Lock is designed to enforce Write-Once-Read-Many (WORM) semantics compatible with the S3 Object Lock API. In vulnerable releases, the enforcement logic in objectlock_sys.rs fails open when it cannot read or parse the bucket's lock configuration. Instead of denying the destructive operation or surfacing an error, the code interprets missing or malformed metadata as "no Object Lock configured."

This behavior is classified under [CWE-693: Protection Mechanism Failure]. It affects several deletion paths: direct API-driven deletes handled by check_object_lock_for_deletion, bulk delete_prefix calls, background lifecycle expiration, and scanner sweeps that reap objects marked for cleanup. Any transient I/O error, corrupted .metadata.bin, or version-mismatch parsing failure is enough to remove the retention barrier for that bucket.

Root Cause

The root cause is a fail-open error-handling pattern. The Object Lock lookup returns success with an implicit "no configuration" outcome for three distinct failure modes (ConfigNotFound, unreadable metadata bytes, unparseable metadata) that should be differentiated. Callers rely on a single boolean signal and do not distinguish "lock definitively absent" from "lock state unknown." The fix introduces explicit configuration state tracking through ObjectLockConfigState and get_object_lock_config_state, along with incarnation-based guards (capture_bucket_metadata_incarnation, update_if_incarnation, delete_if_incarnation) that let callers refuse to act when the configuration cannot be authoritatively resolved.

Attack Vector

Exploitation requires an authenticated principal with permission to issue delete or lifecycle operations against a target bucket. The attacker either waits for a natural metadata read failure or influences bucket metadata to become unreadable or unparseable. Once the enforcement path returns "no lock," the attacker issues object or prefix deletes, or lets a lifecycle rule expire objects that COMPLIANCE retention was supposed to protect. The CVSS 4.0 vector reflects network reachability with high attack complexity and low privileges required.

rust

// Patch excerpt: crates/ecstore/src/api/mod.rs
// Adds explicit ObjectLockConfigState and incarnation-guarded mutations
pub mod metadata_sys {
    pub use crate::bucket::metadata_sys::{
        BucketMetadataMutationGuard, BucketMetadataSys, ObjectLockConfigState,
        acquire_bucket_metadata_transaction_lock,
        capture_bucket_metadata_incarnation, delete, delete_if_incarnation,
        get, get_accelerate_config, get_bucket_policy, get_bucket_policy_raw,
        get_bucket_targets_config, get_config_from_disk, get_cors_config,
        get_durability_config, get_global_bucket_metadata_sys,
        get_lifecycle_config, get_logging_config, get_notification_config,
        get_object_lock_config, get_object_lock_config_state,
        get_public_access_block_config, get_quota_config,
        get_replication_config, get_request_payment_config, get_sse_config,
        get_tagging_config, get_versioning_config, get_website_config,
        init_bucket_metadata_sys, list_bucket_targets, reload_bucket_metadata,
        remove_bucket_metadata, set_bucket_metadata, update,
        update_bucket_targets_under_transaction_lock, update_config_with,
        update_if_incarnation, update_under_transaction_lock,
    };
}
// Source: https://github.com/rustfs/rustfs/commit/98d3619613722308498494d412797a52ea8ae64d

Detection Methods for CVE-2026-73288

Indicators of Compromise

Successful DeleteObject, DeleteObjects, or DeleteObjectVersion responses against objects that were placed under COMPLIANCE-mode Object Lock with a future retain-until-date.
Lifecycle expiration or scanner sweep events removing objects whose retention date has not elapsed.
Errors or warnings in RustFS logs referencing ConfigNotFound, .metadata.bin read failures, or Object Lock configuration parse errors that immediately precede successful deletions.

Detection Strategies

Reconcile object inventories against expected retention state; flag any object whose retain-until-date was in the future but is no longer present.
Correlate RustFS error logs about unreadable or unparseable bucket metadata with subsequent DELETE-class operations on the same bucket.
Compare RustFS binary version reported by nodes against the fixed release 1.0.0-rc.1 and alert on any node running an earlier build.

Monitoring Recommendations

Enable S3-compatible access logging on RustFS and centralize logs in a SIEM or data lake for long-term correlation and audit.
Alert on unexpected delete_prefix volumes and on lifecycle expirations that target Object Lock-enabled buckets.
Monitor the integrity and readability of .metadata.bin files across erasure-coded nodes; a sudden increase in parse failures is a leading indicator.

How to Mitigate CVE-2026-73288

Immediate Actions Required

Upgrade all RustFS nodes to version 1.0.0-rc.1 or later, which introduces the ObjectLockConfigState model and incarnation-guarded metadata mutations.
Restrict s3:DeleteObject, s3:DeleteObjectVersion, and s3:PutLifecycleConfiguration permissions on Object Lock-enabled buckets to a minimal set of principals until the upgrade is complete.
Audit recent deletions against retention manifests to identify any COMPLIANCE-protected objects that were removed prior to patching.

Patch Information

The fix is delivered in RustFS release 1.0.0-rc.1 via pull request #5648 and commit 98d3619. Details and coordinated disclosure are documented in GitHub Security Advisory GHSA-j548-9grx-fh4f. The patch replaces the fail-open pattern with an explicit configuration state and adds incarnation checks so that mutations refuse to proceed when the Object Lock state cannot be authoritatively resolved.

Workarounds

Disable lifecycle expiration rules and pause background scanner sweeps on Object Lock-enabled buckets until nodes are patched.
Enforce deny-by-default IAM policies on delete operations for buckets that hold COMPLIANCE-retained objects.
Maintain out-of-band, immutable backups of critical objects so that a bypass-driven deletion can be reconstructed from an independent copy.

bash

# Verify the running RustFS version and upgrade if below 1.0.0-rc.1
rustfs --version

# Example: temporary IAM policy fragment to deny deletes on locked buckets
cat <<'EOF'
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "s3:DeleteObject",
        "s3:DeleteObjectVersion",
        "s3:PutLifecycleConfiguration"
      ],
      "Resource": [
        "arn:aws:s3:::locked-bucket/*",
        "arn:aws:s3:::locked-bucket"
      ]
    }
  ]
}
EOF