CVE-2026-73284: RustFS Privilege Escalation Vulnerability

CVE-2026-73284 Overview

CVE-2026-73284 is a privilege escalation vulnerability in RustFS, a distributed object storage system written in Rust. The flaw resides in the AddServiceAccount handler at rustfs/src/admin/handlers/service_account.rs. The handler accepts an attacker-controlled target_user value after validating only the CreateServiceAccountAdminAction permission. It then passes that value to new_service_account, and prepare_service_account_auth sets is_owner on the resulting root-parented service account. A caller holding this single admin action can mint a service account parented to the root credential and authenticate as owner. The issue is fixed in RustFS version 1.0.0-beta.11.

Critical Impact
An authenticated low-privilege administrator can escalate to full owner (root) privileges on the RustFS cluster, resulting in complete takeover of stored objects and cluster configuration.

Affected Products

RustFS distributed object storage
All versions prior to 1.0.0-beta.11
Deployments exposing the admin API to holders of CreateServiceAccountAdminAction

Discovery Timeline

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

Technical Details for CVE-2026-73284

Vulnerability Analysis

RustFS separates administrative actions from the identities those actions target. The CreateServiceAccountAdminAction permission gates whether a caller may create service accounts, but not on whose behalf. The AddServiceAccount handler enforced only the action check and then trusted the caller-supplied target_user field. When the handler forwarded that value to new_service_account, the downstream prepare_service_account_auth function inferred ownership from the parent user. Passing the root access key as target_user produced a service account whose credentials authenticated with is_owner = true. This constitutes an improper privilege management flaw [CWE-269] and a broken access control condition.

Root Cause

The root cause is missing scope validation on the target_user parameter during service account creation. The code lacked an ownership check that confined non-owner callers to their own credential scope. Without it, action-level authorization was mistaken for identity-level authorization.

Attack Vector

An authenticated user holding CreateServiceAccountAdminAction sends a crafted admin API request specifying target_user = <root access key>. The server issues service account credentials parented to root. The attacker then uses those credentials to perform any owner-level operation, including reading, modifying, or deleting arbitrary buckets and objects.

rust

     caller_parent == target_parent_user
 }
 
+/// GHSA-5354: whether a caller resolving to `owner` may create a service account
+/// parented to `target_user`, given the caller's own key (`req_user`) and its
+/// effective parent (`req_parent_user`, which equals `req_user` for a top-level
+/// user or the parent for a derived credential).
+///
+/// The `CreateServiceAccountAdminAction` permission gates *whether* a caller may
+/// create service accounts, not *for whom*. A non-owner is therefore confined to
+/// its own scope; only an owner may target another user — including the root
+/// credential, whose existence check is deliberately lenient. Without this a
+/// caller holding only that action could pass `target_user = <root access key>`
+/// and mint a root-parented service account that authenticates as owner via
+/// `prepare_service_account_auth`, a full-takeover privilege escalation. Mirrors
+/// `imported_service_account_parent_allowed` on the ImportIam path (GHSA-566f).
+fn add_service_account_parent_within_scope(target_user: &str, req_user: &str, req_parent_user: &str, owner: bool) -> bool {
+    owner || target_user == req_user || target_user == req_parent_user
+}
+
 /// Fail-closed ownership check used by DeleteServiceAccount for a caller that
 /// lacks the RemoveServiceAccount admin action.

Source: GitHub Commit 9866f68. The patch introduces add_service_account_parent_within_scope, which confines non-owner callers to their own credential scope.

Detection Methods for CVE-2026-73284

Indicators of Compromise

Service accounts whose parent user equals the cluster root access key but were not created by an owner session.
Admin API POST requests to the AddServiceAccount endpoint containing a target_user value matching the root access key.
New access keys issued shortly after login by a user holding only CreateServiceAccountAdminAction.

Detection Strategies

Audit the RustFS IAM store for service accounts with root parentage and correlate against the creator identity in admin API logs.
Alert on any AddServiceAccount call where the caller identity differs from the resolved parent of the target user.
Compare service account inventory before and after upgrading to 1.0.0-beta.11 to identify accounts that would be rejected by the new scope check.

Monitoring Recommendations

Enable verbose admin action logging on the RustFS server and forward logs to a centralized SIEM for correlation.
Monitor for privilege escalations that immediately follow service account creation events.
Track use of newly created access keys against sensitive buckets, especially operations reserved for owner identities.

How to Mitigate CVE-2026-73284

Immediate Actions Required

Upgrade RustFS to version 1.0.0-beta.11 or later without delay.
Rotate the root access key and any service account credentials that could have been created via the vulnerable path.
Revoke CreateServiceAccountAdminAction from users who do not require it until the upgrade is complete.

Patch Information

The fix is delivered in RustFS 1.0.0-beta.11 and tracked in GitHub Pull Request #5141. Full technical details are available in GitHub Security Advisory GHSA-5354-r3w2-34m8 and the release notes for 1.0.0-beta.11.

Workarounds

Restrict network access to the admin API so only trusted operators can reach it.
Remove the CreateServiceAccountAdminAction permission from all non-owner policies until patching is complete.
Audit and delete any service accounts parented to the root credential that were not created by an owner.

bash

# Verify installed RustFS version and upgrade
rustfs --version
# Upgrade to the patched release
docker pull rustfs/rustfs:1.0.0-beta.11
# Enumerate service accounts parented to root for review
rustfs-admin user svcacct list --parent <ROOT_ACCESS_KEY>