Listen to this Post
The vulnerability arises from a flawed `deny_only` short-circuit logic in the RustFS IAM policy evaluation. During service account creation, if the target user equals the caller or its parent, the system sets deny_only=true. The `Policy::is_allowed` function, when `deny_only` is true, returns `true` if no explicit `Deny` statement is matched, entirely skipping the evaluation of any `Allow` statements. Since newly created service accounts lack a session policy by default, their claims do not contain a SESSION_POLICY_NAME. This combination allows a restricted service account or STS credential to issue a new service account for itself or its parent without any policy restrictions. The created child account inherits the full, unrestricted privileges of its parent, leading to privilege escalation from a limited user to root-level access across S3, Admin, and KMS operations.
Platform: RustFS
Version: Not specified
Vulnerability: Privilege escalation
Severity: Critical
date: Not specified
Prediction: Patch date unspecified
What Undercode Say:
!/usr/bin/env bash
set -euo pipefail
ENDPOINT="${ENDPOINT:-http://127.0.0.1:9000}"
ROOT_AK="${ROOT_AK:-rustfsadmin}"
ROOT_SK="${ROOT_SK:-rustfsadmin}"
// crates/policy/src/policy/policy.rs:66-74
if self.deny_only && !matched_deny {
return Ok(Decision::Allowed);
}
// rustfs/src/admin/handlers/service_account.rs:114-127 let deny_only = target_user == caller || target_user == parent;
How Exploit:
1. Obtain restricted credentials.
2. Call service account creation API targeting self/parent.
3. Use new unrestricted credentials.
4. Perform privileged operations.
Protection from this CVE
Apply vendor patch.
Disable vulnerable endpoints.
Implement network isolation.
Impact:
Privilege escalation.
Bypass policy restrictions.
Root-level access compromise.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
