Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate with low-privilege credentials
-
DeliveryCorrupt or remove .metadata.bin in target bucket
-
ExploitIssue delete request or await automated lifecycle sweep
-
ExecutionRustFS interprets metadata error as no-lock state
-
ImpactCOMPLIANCE-locked objects permanently deleted
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V15 - Secure Coding and Architecture Protection mechanism completeness
|
| Exploitation Conditions | Object Lock must be enabled on the affected bucket with COMPLIANCE retention mode or a lifecycle expiry policy configured. Exploitation is triggered when check_object_lock_for_deletion, delete_prefix, or lifecycle and scanner sweep routines encounter one of three metadata error conditions: ConfigNotFound (metadata file absent from storage), unreadable .metadata.bin data (I/O or permission-level read failure), or unparseable metadata content (corruption). An authenticated low-privilege user (consistent with CVSS PR:L) can initiate or influence explicit delete operations; the lifecycle and scanner paths may activate the bypass automatically on a scheduled basis once metadata is in an error state, requiring no further attacker interaction after the initial corruption. Deployments that do not use Object Lock COMPLIANCE retention are not exposed to data loss, though GOVERNANCE-mode bypass may also warrant verification. The high attack complexity (AC:H) and prerequisite condition (AT:P) in the CVSS vector reflect that metadata corruption must precede the protection bypass. |
| Impact | The CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:L/UI:N/VC:N/VI:H/VA:H) scores 6.1 Medium, reflecting network accessibility tempered by high attack complexity and specific prerequisite conditions. Integrity and availability impacts are rated High because successful exploitation allows permanent deletion of COMPLIANCE-locked objects that should be immutable. No EPSS data was supplied and no KEV listing or public exploit exists, limiting near-term opportunistic risk. The vulnerability is most consequential in regulated industries relying on WORM immutability for legal or compliance obligations - even a mid-sized municipal IT team in kielce storing audit records under COMPLIANCE retention would face regulatory exposure if this bypass allowed those records to be silently expired by a lifecycle sweep. The fail-open design flaw is at least as likely to be triggered by organic storage-layer faults (disk errors, failed metadata writes) as by deliberate attacker action, meaning the blast radius extends beyond intentional exploitation. The AC:H and AT:P ratings are consistent with the description's prerequisite conditions; no conflicting signals were observed between the CVSS vector and the textual description. |
| Exploit ScenarioDerived | An authenticated low-privilege user deliberately corrupts or removes the .metadata.bin configuration file for a target bucket, then issues a delete request or waits for a scheduled lifecycle expiry sweep to execute. RustFS encounters the parse or I/O error, concludes that no lock configuration exists, and permanently deletes COMPLIANCE-locked objects that should have been immutable for their full retention period. No public proof-of-concept exploit exists at time of analysis; the attack path is derived from the CVE description and PR #5648 source code changes. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Aug 12, 2026
Object Lock COMPLIANCE retention enforcement in RustFS fails open when bucket metadata is absent, unreadable, or corrupt - treating any metadata error as 'no lock configured' rather than blocking the operation. All RustFS versions prior to 1.0.0-rc.1 are affected, exposing COMPLIANCE-retained objects to unauthorized deletion via explicit delete calls, delete_prefix operations, and automated lifecycle or scanner sweeps. No public exploit or CISA KEV listing exists at time of analysis; the risk is primarily to organizations relying on COMPLIANCE-mode immutability for regulatory or legal-hold data retention obligations.
RemediationAI
Upgrade RustFS to version 1.0.0-rc.1, which corrects the fail-open behavior in check_object_lock_for_deletion, delete_prefix, and lifecycle sweep routines to treat metadata read errors as a lock-present condition (fail closed) rather than lock-absent. The fix is confirmed in GitHub PR #5648 (https://github.com/rustfs/rustfs/pull/5648) and commit 98d3619613722308498494d412797a52ea8ae64d. The full release is available at https://github.com/rustfs/rustfs/releases/tag/1.0.0-rc.1. If an immediate upgrade is not feasible, organizations depending on COMPLIANCE retention for regulatory purposes should disable automated lifecycle expiry policies and restrict delete permissions to the minimum trusted set of principals; the trade-off is that objects will accumulate until manual review, and lifecycle-driven storage cost management is lost. Monitoring .metadata.bin file integrity across bucket storage paths with alerting on unexpected absence or corruption provides a compensating detective control until the upgrade is applied.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
RustFS is a Rust-native distributed object storage system implementing an S3-compatible API, including AWS S3 Object Lock semantics. Object Lock enforces GOVERNANCE and COMPLIANCE retention modes that render objects immutable for a defined period; COMPLIANCE mode cannot be overridden by any user including administrators, making it the strongest immutability guarantee the system offers. The vulnerable code resides in crates/ecstore/src/bucket/object_lock/objectlock_sys.rs, specifically within the check_object_lock_for_deletion, delete_prefix, and lifecycle and scanner sweep routines. CWE-693 (Protection Mechanism Failure) identifies the root cause: the enforcement logic treats three distinct error conditions - ConfigNotFound, unreadable .metadata.bin files, and unparseable metadata content - as semantically equivalent to 'no lock configured,' implementing a fail-open rather than fail-closed posture. The PR diff's test name lifecycle_expiry_fails_closed_on_corrupt_object_lock_metadata directly names the corrected behavior, confirming the fail-open pattern was the root defect. CPE cpe:2.3:a:rustfs:rustfs:*:*:*:*:*:*:*:* covers all pre-fix versions.
Know when Rustfs gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N
Network-accessible service but requires authenticated low-privilege access and a specific metadata-corruption precondition; integrity and availability both high due to permanent deletion of immutability-locked objects.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
1DescriptionCVE.org
RustFS is a distributed object storage system built in Rust. Prior to 1.0.0-rc.1, RustFS Object Lock enforcement in crates/ecstore/src/bucket/object_lock/objectlock_sys.rs lets check_object_lock_for_deletion, delete_prefix, and lifecycle and scanner sweeps treat ConfigNotFound, unreadable .metadata.bin data, or unparseable metadata as no lock configuration, allowing objects under COMPLIANCE retention to be deleted or expired. This issue is fixed in version 1.0.0-rc.1.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
RustFS (alpha.13 to alpha.78) has a privilege escalation where restricted service accounts can self-issue unrestricted c
Stored XSS in RustFS distributed object storage system before 1.0.0-alpha.83. Malicious JavaScript persists in stored ob
Incorrect IAM permission validation in RustFS prior to version 1.0.0-alpha.79 permits principals with export-only permis
Path traversal in the RustFS /rustfs/rpc/read_file_stream endpoint allows an attacker to read arbitrary files from the h
RustFS versions 1.0.0-alpha.1 through 1.0.0-alpha.79 expose the shared HMAC secret in server logs when processing invali
Authentication bypass in RustFS distributed object storage (versions prior to 1.0.0-beta.2) allows unauthenticated remot
RustFS is a distributed object storage system built in Rust. [CVSS 4.0 MEDIUM]
Privilege escalation in RustFS distributed object storage before 1.0.0-beta.2 lets a low-privileged user holding ImportI
Stored cross-site scripting in RustFS Console (0.1.7 through 0.1.9) lets an attacker upload an HTML payload disguised as
Privilege escalation in RustFS prior to version 1.0.0-beta.11 allows any authenticated user holding CreateServiceAccount
Unauthenticated denial of service and information disclosure in RustFS distributed object storage prior to version 1.0.0
License-enforcement bypass in RustFS distributed object storage (versions prior to 1.0.0-beta.2) stems from a hardcoded
EUVD-2026-57233
NVD
CVE.org
EPSS
Vulnrichment
GitHub
VulDB
Exploit-DB