RustFS vulnerabilities

In RustFS prior to 1.0.0-beta.12, an anonymous ListObjectVersions request that lacks a direct bucket-policy grant falls back to an s3:ListBucket check and returns before the policy_allowed path applies deny_anonymous_table_data_plane_if_needed and RestrictPublicBuckets. This allows a bucket that permits anonymous listing to continue exposing version listings after an operator enables public-access control.

RustFS before version 1.0.0-beta.12 has incorrect evaluation of ForAllValues: and ForAnyValue: qualifiers with negated string operators, potentially granting access to excluded principals or making Deny rules ineffective.

RustFS before version 1.0.0-beta.12 has a vulnerability where get_condition_values folds attacker-controlled request headers into identity-based condition keys such as userid, username, principaltype, groups, versionid, signatureversion, jwt:, and ldap:. This allows authenticated callers to satisfy identity-based policy conditions.

RustFS from version 1.0.0-alpha.64 until 1.0.0-rc.1, when external OPA authorization is enabled via RUSTFS_POLICY_PLUGIN_URL, sets PreparedIamAuth.needs_existing_object_tag incorrectly for PreparedIamMode::Opa, causing maybe_merge_object_tag_conditions to omit s3:ExistingObjectTag/* values. This allows authenticated users to bypass tag-based policy restrictions.

RustFS before version 1.0.0-alpha.79 has a vulnerability in the ImportIam admin API that incorrectly validates permissions using ExportIAMAction instead of ImportIAMAction. This allows a principal with export-only IAM permissions to perform import operations. Since importing IAM data performs privileged write actions (creating/updating users, groups, policies, and service accounts), this can lead to unauthorized IAM modification and privilege escalation. Version 1.0.0-alpha.79 fixes the issue.

In RustFS prior to version 1.0.0-beta.2, a vulnerability exists in the PUT /rustfs/admin/v3/import-iam endpoint. Improper validation allows a user with ImportIAMAction to create service accounts under arbitrary parent identities, including the root user (minioadmin). An attacker can set their own credentials, leading to privilege escalation to full administrative access.

In RustFS versions 1.0.0-alpha.13 through 1.0.0-alpha.78, a flawed `deny_only` short-circuit in RustFS IAM allows a restricted service account or STS credential to self-issue an unrestricted service account, inheriting the parent’s full privileges. This enables privilege escalation and bypass of session/inline policy restrictions. Version 1.0.0-alpha.79 fixes the issue.

RustFS versions 1.0.0-alpha.13 to 1.0.0-alpha.78 contain a path traversal vulnerability in the /rustfs/rpc/read_file_stream endpoint. This has been patched in version 1.0.0-alpha.79.

RustFS is a distributed object storage system built in Rust. In versions prior to 1.0.0-alpha.78, RustFS implements gRPC authentication using a hardcoded static token `"rustfs rpc"` that is publicly exposed in the source code repository, hardcoded on both client and server sides, non-configurable with no mechanism for token rotation, and universally valid across all RustFS deployments. Any attacker with network access to the gRPC port can authenticate using this publicly known token and execute privileged operations including data destruction, policy manipulation, and cluster configuration changes. Version 1.0.0-alpha.78 contains a fix for the issue.

In RustFS prior to 1.0.0-rc.1, Object Lock enforcement 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.

In RustFS prior to 1.0.0-beta.12, FTPS MKD handling in FtpsDriver::mkd calls storage.create_bucket without authorize_operation for S3Action::CreateBucket, allowing authenticated FTPS users denied s3:CreateBucket to create buckets.

RustFS AddServiceAccount in rustfs/src/admin/handlers/service_account.rs accepts an attacker-controlled target_user after only checking CreateServiceAccountAdminAction, passes it to new_service_account, and prepare_service_account_auth sets is_owner for the resulting root-parent service account. This allows privilege escalation.

In RustFS, explicit versionId reads in GetObject, CopyObject sources, and UploadPartCopy sources are authorized with s3:GetObject instead of s3:GetObjectVersion, allowing principals without historical-version permission to disclose known historical object content.

In RustFS from version 1.0.0-alpha.1 to 1.0.0-beta.9, when the FTP frontend is enabled, the read and probe handlers (RETR, SIZE, MDTM, CWD) bypass the IAM authorization function, allowing any authenticated FTP user to read and stat any object in any bucket regardless of their IAM policy.

In RustFS 1.0.0-beta.4, authenticated users with PutObject permission on their own bucket can exploit a path traversal vulnerability in the Snowball auto-extract feature to write arbitrary objects into other users' buckets, completely breaking multi-tenant isolation. The vulnerability chains three flaws: no ../ sanitization in tar entry key normalization, IAM wildcard matching using raw (uncleaned) paths, and filesystem path cleaning resolving ../ across bucket boundaries.

RustFS is a distributed object storage system where prior to alpha.90, there is a missing authorization check in the multipart copy path (UploadPartCopy). A low-privileged user who cannot read objects from a victim bucket can copy victim objects into an attacker-controlled multipart upload and complete the upload.