CVE-2026-73265 in RustFS
Summary
by MITRE • 08/12/2026
RustFS is a distributed object storage system built in Rust. RustFS authorizes explicit versionId reads in GetObject, CopyObject sources, and UploadPartCopy sources with s3:GetObject instead of s3:GetObjectVersion, allowing principals without historical-version permission to disclose known historical object content. This issue is fixed in version 1.0.0-beta.11.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/12/2026
RustFS represents a distributed object storage system implemented in the Rust programming language, designed to provide scalable and secure data storage capabilities. The system operates as a cloud-native storage solution that supports various S3-compatible operations including object retrieval, copying, and multipart uploads. The vulnerability under discussion affects the authorization mechanisms within this storage system, specifically impacting how versioned objects are accessed and retrieved. This flaw manifests in the system's handling of explicit versionId references during critical operations such as GetObject, CopyObject sources, and UploadPartCopy sources.
The technical flaw stems from an improper permission check implementation where RustFS utilizes s3:GetObject authorization instead of the more restrictive s3:GetObjectVersion permission when processing operations involving explicit versionId parameters. This misconfiguration creates a privilege escalation scenario where users who possess only basic object read permissions can potentially access historical versions of objects that they should not be authorized to view. The vulnerability essentially allows unauthorized disclosure of historical object content through legitimate operational pathways that should require elevated permissions.
The operational impact of this vulnerability is significant as it undermines the fundamental security model of versioned storage systems. Principals who lack proper historical-version permissions can exploit this flaw to access sensitive data from previous versions of objects, potentially exposing confidential information that was intended to be protected. This disclosure occurs during normal operational workflows including object retrieval, copying operations between versioned buckets, and multipart upload processes where versionId references are explicitly provided. The vulnerability affects the integrity and confidentiality aspects of the system's security posture, particularly in environments where data retention policies and version control mechanisms are critical for compliance and audit requirements.
This issue aligns with CWE-284 (Improper Access Control) and represents a specific instance of inadequate authorization checks in distributed storage systems. The flaw demonstrates poor adherence to the principle of least privilege, where access controls should be strictly enforced based on explicit permissions rather than default assumptions about object access patterns. From an ATT&CK perspective, this vulnerability maps to T1078 (Valid Accounts) and T1566 (Phishing) as it allows for unauthorized access through legitimate system interfaces, potentially enabling adversaries to discover sensitive information without requiring additional compromise techniques.
Mitigation strategies for this vulnerability include upgrading to version 1.0.0-beta.11 where the authorization logic has been corrected to properly enforce s3:GetObjectVersion permissions for operations involving explicit versionId references. System administrators should also implement comprehensive access control reviews to ensure that principals have appropriate permission levels based on their operational requirements. Additional monitoring and logging should be implemented to detect unusual patterns of object access that might indicate exploitation attempts, particularly around versioned object operations. Organizations should conduct security assessments of their storage systems to identify similar authorization flaws that might exist in other components or related services within their infrastructure ecosystem.
The fix addresses the core authorization issue by ensuring that all operations involving explicit versionId parameters require the appropriate s3:GetObjectVersion permission rather than the more permissive s3:GetObject permission. This change restores proper access control boundaries and ensures that historical object content remains protected according to the defined permission model. System administrators should verify that the upgrade process is completed successfully and validate that access controls function as expected through comprehensive testing of versioned object operations across different user roles and permission levels.