Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
10 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
ListServiceAccount (GET /rustfs/admin/v3/list-service-accounts?user=<other) authorizes cross-user requests against UpdateServiceAccountAdminAction instead of ListServiceAccountsAdminAction at rustfs/src/admin/handlers/serviceaccount.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/serviceaccount.rs:489 performs no ownership check on the target access key, leaking those access keys lets a delegated "service account updater" role overwrite…
Recommended action: Upgrade to 1.0.0-alpha.98 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. 1. 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). 2. Insecure Preview Implementation: In console/components/object/preview-modal.vue, the application…
Recommended action: Upgrade to 1.0.0-alpha.83 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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: 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,…
Recommended action: Upgrade to 1.0.0-alpha.82 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
IP-based access control can be bypassed: getconditionvalues 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 remoteaddr from X-Forwarded-For/X-Real-Ip, then inserts SourceIp via getsourceipraw, with no trust boundary or proxy validation: - let remoteaddr = header.get("x-forwarded-for").andthen(...).orelse(|| header.get("x-real-ip")...).unwrapor("127.0.0.1"); - args.insert("SourceIp", vec![getsourceipraw(header, remoteaddr)]); - 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…
Recommended action: Upgrade to 1.0.0-alpha.78 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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/httpauth.rs:115-122 , the invalid signature branch logs sensitive data: This log line includes secret and expectedsignature, 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 1. Run RustFS with error logging enabled. 1. Send a request with an invalid signature: 1. Observed output: 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.
Recommended action: Upgrade to 1.0.0-alpha.80 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A flawed denyonly 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::isallowed returns true when denyonly=true if no explicit Deny is hit, skipping all Allow checks (crates/policy/src/policy/policy.rs:66-74). - Service account creation path sets denyonly=true when the target user equals the caller or its parent (rustfs/src/admin/handlers/serviceaccount.rs:114-127). - Service accounts are created without sessionpolicy by default, so claims lack SESSIONPOLICYNAME; combined with denyonly, 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…
Recommended action: Upgrade to 1.0.0-alpha.79 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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: 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 1. A RustFS deployment with IAM enabled. 2. An IAM user or role that has Export IAM permission but does not have Import IAM or full admin permissions. 3. Access credentials for that user. Steps 1. Create or obtain an IAM principal with permission…
Recommended action: Upgrade to 1.0.0-alpha.79 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A malformed gRPC GetMetrics request causes getmetrics to unwrap() failed deserialization of metrictype/opts, panicking the handler thread and enabling remote denial of service of the metrics endpoint. Details - Vulnerable code: rustfs/src/storage/tonicservice.rs:1775-1782: - MetricType and CollectMetricsOpts are deserialized with Deserialize::deserialize(...).unwrap() from client-supplied bytes. - Malformed metrictype/opts (e.g., empty or truncated rmp-serde payloads) trigger InvalidMarkerRead and panic. - Reachability: same TCP listener as S3 (default :9000); only a static interceptor token authorization: rustfs rpc is checked in server/http.rs:677. - Impact scope: panic terminates the worker handling the request, causing metrics service interruption and potential process instability. PoC rustfs-grpc-metrics-invalid-metric-type-panic-poc.tar.gz 1) Start RustFS (example local dev): 2) From rustfs-grpc-metrics-invalid-metric-type-panic-poc/, run: 3) Observe panic in server…
Recommended action: Upgrade to 1.0.0-alpha.78 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Recommended action: Upgrade to 1.0.0-alpha.79 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Vulnerability Overview Description RustFS implements gRPC authentication using a hardcoded static token "rustfs rpc" that is: 1. Publicly exposed in the source code repository 2. Hardcoded on both client and server sides 3. Non-configurable with no mechanism for token rotation 4. Universally valid across all RustFS deployments Any attacker with network access to the gRPC port can authenticate using this publicly known token and execute privileged operations including data destruction, policy manipulation, and cluster configuration changes. CVSS 3.1 Score Score: 9.8 (Critical) Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H - Attack Vector (AV): Network - Exploitable remotely - Attack Complexity (AC): Low - No special conditions required - Privileges Required (PR): None - No authentication needed (bypassed) - User Interaction (UI): None - Fully automated exploitation - Scope (S): Unchanged - Impact contained to vulnerable component - Confidentiality (C): High - Complete data…
Recommended action: Upgrade to 1.0.0-alpha.78 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.