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

Exploitation

No confirmed exploitation recorded. Patch Next marks exploitation only from CISA KEV.

CVSS 4.0

5.7 · CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P · score source

EPSS

• CVE-2026-22043: 0.42% estimated exploitation activity in the next 30 days; percentile 36.31 (FIRST EPSS, 2026-11-03). This is a model estimate, not proof of exploitation or customer exposure.

As published by the source; long descriptions are shortened.

Summary 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…

Published by the source

8 Jan 2026, 20:40 UTC

Last modified by the source

8 Jan 2026, 20:40 UTC

Source last checked

26 Oct 2026, 15:39 UTC

1. Revision 1 · created · 26 Oct 2026

   Published from ghsa record GHSA-xgr5-qc6w-vcg9

Preview the exact text before you copy it. Commands are read-only suggestions; review them before running anything.

# Patch Next advisory brief: CVE-2026-22043

Advisory: RustFS has IAM deny_only Short-Circuit that Allows Privilege Escalation via Service Account Minting
IDs: CVE-2026-22043, GHSA-xgr5-qc6w-vcg9
Record: https://patchnext.com/advisories/cve-2026-22043 (revision 1, source checked 26 Oct 2026, 15:39 UTC)
Inventory: none attached. This brief comes from a public page and does not say whether any deployment is affected.
Severity: Medium (CVSS 5.7)
Exploitation: no confirmed exploitation recorded. Patch Next confirms exploitation only from CISA KEV.
Vendor response: Vendor fix available; fixed versions by package: rustfs 1.0.0-alpha.79. A vendor fix does not mean a deployment is fixed.

## Affected components
- crates.io rustfs: affected >= 1.0.0-alpha.13, <= 1.0.0-alpha.78; fixed in 1.0.0-alpha.79

## Suggested inspection (read-only)
- crates.io rustfs: check the installed version with your package manager.

## Supported action
Upgrade each affected component to a fixed version on its release line. For a transitive dependency, upgrade the parent package or add an override or constraint, then regenerate the lockfile. Redeploy every environment that ran an affected version.

## Required regression checks
- Run the test suite and a production build.
- Exercise the features that depend on rustfs.
- Repeat the inspection and confirm that only fixed versions remain installed.

## Rollback considerations
- Keep the previous lockfile and deployment artifact. Rolling back reinstates the vulnerable version, so apply any documented mitigation while you fix forward.

## Unresolved questions
- Which deployments run an affected version?
- Exploitation status can change. Check again before lowering the priority.
- Mark the work resolved only after the fixed version is verified in production.

## Sources
- Verified: https://github.com/advisories/GHSA-xgr5-qc6w-vcg9 (GitHub-reviewed advisory GHSA-xgr5-qc6w-vcg9 lists affected ranges: crates.io rustfs >=1.0.0-alpha.13 <=1.0.0-alpha.78)

Commands are suggestions: review each one before running it.