RustFS EUVD-2026-57234

Exploitation requires that the target RustFS deployment has at least one IAM policy using ForAllValues: or ForAnyValue: set qualifiers in combination with one of the five negated operators: StringNotEquals, StringNotEqualsIgnoreCase, StringNotLike, ArnNotEquals, or ArnNotLike. The attacker must be authenticated (CVSS PR:L - unauthenticated exploitation is not enabled by this flaw). The triggering condition further requires that the attacker's request values partially overlap with the policy's condition values - a fully disjoint or fully overlapping value set may not invert the result. Policies that use only non-negated operators (StringEquals, StringLike, ArnEquals) are entirely unaffected. Absent condition keys in requests (e.g., no jwt:groups claim present) also receive inverted ForAllValues/ForAnyValue treatment, which can cause vacuously-satisfied ForAllValues conditions to fail or vice versa. Deployments using jwt:groups or jwt:roles for RBAC-style group enforcement with negated exclusion conditions are the highest-risk configurations.

The official CVSS 8.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N) reflects network-accessible exploitation requiring only low-privilege authentication, with high confidentiality and integrity impact. However, AC:L warrants scrutiny: the vulnerability only activates when target IAM policies are specifically configured with negated operators (StringNotEquals, StringNotLike, etc.) combined with ForAllValues: or ForAnyValue: set qualifiers - this is not a default or ubiquitous configuration pattern. An independent assessment of AC:H is more appropriate, as the attacker depends on a non-default policy structure being present in the target environment. No EPSS data was provided in the input; exploitation probability is inferred as low-to-moderate given the policy configuration dependency. There is no CISA KEV listing, and no public exploit code is known. The product is in pre-1.0 beta, constraining real-world exposure. The most realistic high-risk scenario involves organizations using jwt:groups or jwt:roles for RBAC enforcement, where a Deny guardrail using ForAllValues:StringNotEquals silently inverts to an Allow.

An authenticated low-privilege user identifies that a restrictive Deny policy uses ForAllValues:StringNotEquals on the jwt:groups condition key to exclude their group from a sensitive bucket. Because the policy engine incorrectly negates the aggregate result rather than each predicate, submitting a request with a jwt:groups claim that partially overlaps the excluded set causes the Deny evaluation to return the wrong boolean, and the request is permitted instead of denied. No public exploit code exists, but the logic inversion is mechanically predictable from the description.