CVE-2026-73289

This vulnerability stems from a fundamental misunderstanding in how negation interacts with quantifiers in policy evaluation. The correct semantics for `ForAllValues:StringNotEquals` require testing that every request value fails to match every policy value — the logical form `∀r ∈ request: ∀p ∈ policy: p ≠ r`. The buggy implementation inverted this: it checked whether all policy values failed to match all request values, producing `∀p ∈ policy: ∀r ∈ request: p ≠ r`. These are not equivalent when sets partially overlap or when keys are absent from the request — in those cases, the bug produces the opposite result of what correctness demands. The critical failure is that this error survives standard unit testing. The most common test patterns — full match and complete mismatch — produce identical results under both correct and buggy semantics. Only partially overlapping sets or absent request keys expose the flaw. If your test suite lacks coverage for these conditions, every test passes while the logic remains fundamentally broken. You should audit your policy evaluation logs for authorization decisions where request keys were missing or where policy and request values had partial overlap. If you deployed any RustFS beta version prior to 1.0.0-beta.12, treat the authorization state as potentially incorrect — review access logs for the affected window and re-validate any permissive policies involving `StringNotEquals` or `StringNotLike` with `ForAllValues`. The deeper concern is scope. This error likely affects the entire negated-operator family (`StringNotEquals`, `StringNotLike`, potentially `NumericNotEquals`) when combined with `ForAllValues`. Review whether your policies use any of these combinations. Additionally, look for other quantifier × operator interactions in your codebase that may have the same inverted logic — this is a systematic conceptual error, not a single typo.

Reviewed through automated stages and approved by a human before publication.