An attacker gets hold of a restricted service account credential, scoped down and least-privileged, exactly as your team intended. In a correctly implemented system, that is a contained problem. In MinIO before RELEASE.2025-10-15T17-29-55Z, a restricted account could create a new service account for itself, one that inherits the parent user's full privileges without any policy restrictions. The blast radius of a credential compromise just became the blast radius of the entire parent account.
TLDR:
- CVE-2025-62506 lets a restricted MinIO service account create a new account with full parent privileges.
- All MinIO versions prior to RELEASE.2025-10-15T17-29-55Z are vulnerable (CVSS score 8.1, HIGH).
- The flaw stems from DenyOnly logic in session policy validation that checks denial, not explicit allow.
- MinIO has a pattern of IAM bugs; two 2026 authentication bypasses (CVE-2026-40344, CVE-2026-41145, both CVSS score 8.8 HIGH) followed.
- The open-source repo was archived in April 2026; unpatched deployments are effectively unmaintained.
What is MinIO, and which deployments are vulnerable to CVE-2025-62506?
MinIO is a high-performance, S3-compatible object storage system deployed widely across enterprise, government, and cloud-native environments. Teams run it on bare metal, in Kubernetes clusters, and in private cloud setups where they want full control over object storage without going through AWS. Its IAM model closely mirrors the AWS model: service accounts, STS credentials, and inline or session policies are all first-class concepts.
If your team uses service accounts or STS credentials with scoped-down session or inline policies to limit what a given application or pipeline can touch, you are in the affected population. That is exactly the configuration CVE-2025-62506 targets.
How CVE-2025-62506 works: the DenyOnly session policy bypass
MinIO's IAM model mirrors AWS: when a service account carries a session or inline policy, the effective permissions are the intersection of that session policy and the parent user's base policy.
The flaw lives in the policy validation code that runs when a restricted service or STS account calls CreateServiceAccount or UpdateServiceAccount to create a new service account. The code assesses the session policy using a DenyOnly argument. That flag changes the question being asked: instead of "does this policy explicitly allow this action?", the code asks "does this policy explicitly deny this action?". If the session policy doesn't mention service account creation at all, the answer is no, and the action is permitted.
In practice, most scoped-down session policies don't bother explicitly denying CreateServiceAccount. Why would they? The expectation is that anything not explicitly allowed is blocked. But with DenyOnly logic in place, silence equals permission. The restricted account creates a new service account, and that new account carries the full privileges of the parent user: no session policy attached, no scope restrictions, and full access to every bucket and object the parent can access.
The fix in pull request #21642 corrects the validation logic so that session policies must explicitly allow an action for it to proceed, restoring the intended intersection model. The patch shipped in RELEASE.2025-10-15T17-29-55Z.
Field | Detail |
|---|---|
Product | MinIO object storage |
Affected versions | All versions prior to |
Vulnerable configurations | Any deployment using service accounts or STS accounts with restricted session or inline policies |
Severity | CVSS score 8.1 (HIGH), assigned by GitHub (CNA) |
Fix version |
|
CVE reference |
MinIO's recurring IAM vulnerabilities: a history of authorization logic errors
CVE-2025-62506 is the third IAM-related privilege escalation in MinIO in under two years, and that count doesn't include the two 2026 authentication bypasses that followed it.
CVE-2024-24747: access key privilege inheritance
A new access key inherits the full permissions of its parent user, even when the parent carries a restricted session policy. Same class of flaw, different code path.
CVE-2024-55949: IAM import API and site replication privilege escalation
MinIO's site replication feature uses an IAM import API to synchronize IAM state (users, service accounts, and policy documents) across clusters. The vulnerability allows an attacker to import a crafted policy document through that API, granting themselves higher permissions that the authorization layer should have blocked. The site replication import path skipped the permission checks applied to normal policy assignment, so the escalation succeeded without any existing administrative access. Same class of logic error as CVE-2025-62506: a check that ran at the wrong point in the evaluation chain, or not at all.
MinIO's engineering team has historically responded quickly. Advisories are detailed, patches ship fast. But speed of response doesn't change the underlying picture: the access control layer has been a consistent source of authorization logic errors across multiple releases and multiple code paths. That's worth factoring into your risk model independent of any single CVE.
MinIO in 2026: repository archived, new CVEs disclosed
The minio/minio open-source repository was archived by its maintainers on April 25, 2026, and is now read-only. Active development has moved to MinIO AIStor. Organizations still running the open-source MinIO build and unpatched against CVE-2025-62506 should treat those deployments as effectively unmaintained and focus on migrating to a supported AIStor release.
The pattern of access control and authentication failures in MinIO's codebase has continued into 2026, with two authentication bypasses disclosed in April.
CVE-2026-40344: Snowball handler authentication bypass
CVE-2026-40344, disclosed in April 2026 with a CVSS score of 8.8 (HIGH, CNA: GitHub), describes an authentication bypass in MinIO's Snowball auto-extract handler (PutObjectExtractHandler). The handler's switch rAuthType block has no case for authTypeStreamingUnsignedTrailer, so execution falls through with zero signature verification. An attacker sends a PUT request with X-Amz-Meta-Snowball-Auto-Extract: true and an Authorization header containing a valid access key with a completely fabricated signature. The request is accepted, and the tar payload is extracted into the bucket. The fix shipped in AIStor RELEASE.2026-04-11T03-20-12Z.
CVE-2026-41145: PutObject unsigned payload authentication bypass
A separate April 2026 authentication bypass, CVE-2026-41145 (CVSS score 8.8 HIGH, CNA: GitHub), targets the STREAMING-UNSIGNED-PAYLOAD-TRAILER code path in PutObjectHandler and PutObjectPartHandler. Those handlers gate signature verification on the presence of the Authorization header. An attacker omits that header and passes credentials exclusively via the X-Amz-Credential query parameter; the signature check never runs, and the request proceeds with the permissions of the impersonated access key. The same AIStor RELEASE.2026-04-11T03-20-12Z release patches both CVEs.
Taken together, CVE-2025-62506 and the 2026 follow-ons reflect a recurring pattern of authorization and authentication gaps across MinIO releases. Active patch management, regular service account auditing, and tracking the AIStor release cadence remain the most reliable controls for any MinIO deployment.
Catching IAM policy logic errors before they reach production with ZeroPath
The DenyOnly flaw at the core of CVE-2025-62506 is not a missing check. It is a check that asks the wrong question. That kind of authorization logic error does not surface in a typical code review because the code looks intentional: it is doing something, just not the right thing. ZeroPath's SAST engine traces policy evaluation paths through the codebase and flags cases where the logic deviates from the intended access model, catching privilege-escalation vectors like this one before they ship.
The same gap exists at the infrastructure layer. If your service accounts are being created without session policies attached, the DenyOnly bypass is exploitable by anyone who gets hold of those credentials. ZeroPath's IaC scanning flags service account configurations missing the scoped policies that are supposed to be in place, surfacing that risk before it reaches production.
If your team is still running MinIO, ZeroPath's SCA goes beyond version matching. It uses reachability analysis to confirm whether the vulnerable CreateServiceAccount code path is actually reachable in your environment. With the minio/minio repository archived in April 2026, a vulnerable open-source deployment goes beyond a version number to track. It is a remediation priority.
Final thoughts on MinIO's IAM flaw pattern and your security posture
The DenyOnly logic flaw in CVE-2025-62506 turned a scoped-down service account into a full-privilege bypass by treating silence as permission, an authorization error that's structurally hard to catch in code review and easy to miss in an audit. MinIO's IAM layer has been a consistent source of privilege escalation and authentication bypass bugs across multiple releases, and the April 2026 archival of the open-source repository means any deployment still on that build is running unmaintained code. ZeroPath traces policy evaluation paths and surfaces cases where the logic deviates from the intended access model, catching privilege-escalation vectors before they ship. For teams still running MinIO, migration to a supported AIStor release and regular service account auditing are the most reliable controls, and active patch management is the only thing standing between you and the next bypass.
FAQ
How does CVE-2025-62506 actually let a restricted MinIO service account bypass session policies?
The vulnerability exploits a flaw in MinIO's policy validation logic that uses a DenyOnly argument when checking whether a restricted service account can create new service accounts. Instead of asking "does the session policy explicitly allow this action?", the code asks "does the session policy explicitly deny this action?" Anything not explicitly denied gets permitted, even when the session policy never granted the permission in the first place.
MinIO CVE-2025-62506 vs CVE-2024-24747: what's the actual difference?
Both are privilege-escalation bugs in MinIO's IAM layer that allow restricted accounts to bypass session policy limits, but they target different code paths. CVE-2025-62506 exploits the service account creation validation logic using DenyOnly checks, while CVE-2024-24747 allowed new access keys to inherit full parent permissions without applying session policy restrictions. Same architectural weakness, different entry points.
Can I detect CVE-2025-62506 exposure in my MinIO deployment without upgrading?
If you're running any MinIO version before RELEASE.2025-10-15T17-29-55Z and using service accounts or STS credentials with scoped session or inline policies, you're in the vulnerable population. The open-source minio/minio repository was archived in April 2026, so any deployment still on that build is effectively unmaintained. SCA tools with reachability analysis can flag the vulnerable version and confirm whether the affected code paths are reachable, but patching to AIStor RELEASE.2025-10-15T17-29-55Z or later is the only real fix.
When should I treat MinIO's IAM vulnerabilities as a systemic risk instead of isolated bugs?
When the same class of authorization logic error ships across multiple releases and multiple code paths. CVE-2025-62506, CVE-2024-24747, and CVE-2024-55949 all stem from policy validation checks that ask the wrong question at the wrong time. The April 2026 authentication bypasses (CVE-2026-40344, CVE-2026-41145) extended that pattern into signature verification. If your risk model depends on least-privilege service accounts remaining in place even after a credential compromise, MinIO's track record makes active patch management and regular IAM auditing first-class controls, not optional ones.
