CVE-2026-22043 is a privilege escalation flaw in RustFS IAM, scored 9.8 (Critical) by NVD. A restricted service account or STS credential can create an unrestricted service account and inherit the parent's full rights. Versions 1.0.0-alpha.13 through alpha.78 are affected, and alpha.79 fixes it, so upgrade and review the service accounts you have.
What's affected
- Product: RustFS, a distributed object storage system written in Rust
- Affected: 1.0.0-alpha.13 through 1.0.0-alpha.78
- Fixed: 1.0.0-alpha.79
- Package: the advisory lists the Rust crate rustfs
- Status: not in the CISA Known Exploited Vulnerabilities catalog
The GitHub advisory rates the issue Moderate, while NVD scores it 9.8 with no privileges required. The advisory describes the attacker as someone who already holds a restricted service account or STS credential, so the realistic starting point is a credential that exists but was meant to be limited.
How to check if you're exposed
RustFS is deployed as a binary or a container, so start with the version you run. Check the image tag or the release you installed, and compare it with the range above. Anything from alpha.13 to alpha.78 is affected.
Then audit what the policy engine may already have created. List service accounts and temporary credentials, and look for ones that you do not recognise, or that have broader policies than the credential that created them.
Check which applications hold restricted credentials, such as those embedded in CI jobs or shared with partners. Those are the credentials an attacker would start from.
What to do now
- Upgrade every RustFS deployment to 1.0.0-alpha.79 or later.
- List all service accounts and STS credentials. Remove any you cannot trace to a person or a system you own.
- Rotate restricted credentials that have been shared widely or stored in places you do not control, as they are the starting point for this flaw.
- Review access logs from before the upgrade for service account creation by credentials with limited policies.
- Keep object storage off the public internet where you can, and require authentication on every endpoint.
Why it matters
Object stores decide access with policies: lists of what a credential may do. The advisory says RustFS had a shortcut in how it evaluated those policies. When a flag called deny_only was set, the function returned true if no explicit deny rule applied, and it skipped the allow checks entirely. A restricted credential could then ask for a new service account and receive one without the limits.
The result is that session and inline policies, which exist to narrow a credential, stopped narrowing. The weaknesses listed are CWE-269, improper privilege management, CWE-284, improper access control, and CWE-522, insufficiently protected credentials. The advisory notes that the logic is akin to an earlier issue in MinIO, CVE-2025-62506, which suggests that policy engines for S3 style storage share this class of mistake.
For defenders, the lesson is that least privilege only works if the engine enforces it. Limited credentials are often handed to build systems and third parties on the assumption that they cannot grow. Upgrading closes this path, and an audit of existing service accounts tells you whether it was used.
The affected range covers alpha builds, so pin the exact version you run and track its releases the way you would any component that stores your data.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Do I need valid credentials to use this?
The advisory describes a restricted service account or STS credential as the starting point. NVD scores it with no privileges required, so check both views and treat leaked limited credentials as dangerous.
How do I know if it was used?
Look for service accounts created by credentials that were supposed to be limited, and for new accounts with broader policies than their creator. Remove anything unexplained after the upgrade.
Sources
Last reviewed: 19 October 2026.
