CVE-2025-62506 Overview
CVE-2025-62506 is a privilege escalation vulnerability in MinIO, a high-performance object storage system. The vulnerability affects all versions prior to RELEASE.2025-10-15T17-29-55Z and allows service accounts and STS (Security Token Service) accounts with restricted session policies to bypass their inline policy restrictions when performing operations on their own account, specifically when creating new service accounts for the same user.
Critical Impact
An attacker with valid credentials for a restricted service or STS account can create a new service account without policy restrictions, gaining full parent privileges and enabling unauthorized access to buckets and objects beyond their intended restrictions.
Affected Products
- MinIO versions prior to RELEASE.2025-10-15T17-29-55Z
- MinIO service accounts with restricted session policies
- MinIO STS (Security Token Service) accounts with inline policy restrictions
Discovery Timeline
- 2025-10-16 - CVE CVE-2025-62506 published to NVD
- 2025-10-23 - Last updated in NVD database
Technical Details for CVE-2025-62506
Vulnerability Analysis
The vulnerability exists in MinIO's IAM policy validation logic where the code incorrectly relied on the DenyOnly argument when validating session policies for restricted accounts. When a session policy is present, the system should validate that the action is allowed by the session policy, not just that it is not denied. This flaw in authorization logic (CWE-863: Incorrect Authorization) enables restricted accounts to escape their policy boundaries.
The attack can be executed over the network by authenticated users with low-privilege service accounts or STS tokens. The impact includes unauthorized access to confidential bucket contents and the ability to modify or delete objects outside the authorized scope. While availability is not directly impacted, the confidentiality and integrity implications are severe.
Root Cause
The root cause lies in the IAM session policy validation function within cmd/iam.go. The code incorrectly determined when a session policy should be enforced. Specifically, the logic for detecting whether a policy was intentionally empty versus intentionally restrictive was flawed. When the policy had an empty Version, Statements, and ID fields, the system would incorrectly set hasSessionPolicy=false, allowing the account to inherit full parent privileges instead of being restricted.
Attack Vector
An attacker with valid credentials for a restricted MinIO service account or STS token can exploit this vulnerability by creating a new service account for themselves. Due to the policy validation bypass, the newly created service account inherits full parent privileges rather than being bound by the original inline policy restrictions. This allows the attacker to:
- Access buckets and objects beyond their intended restrictions
- Modify, delete, or create objects outside their authorized scope
- Effectively escalate privileges from a restricted account to a fully privileged account
The fix addresses this by properly returning hasSessionPolicy=false only when the policy is empty in all fields, ensuring restrictive session policies are properly enforced.
// policy, regardless of whether the number of statements is 0, this
// includes `null`, `{}` and `{"Statement": null}`. In fact, MinIO Console
// sends `null` when no policy is set and the intended behavior is that the
- // service account should inherit parent policy.
- //
- // However, for a policy like `{"Statement":[]}`, the intention is to not
- // provide any permissions via the session policy - i.e. the service account
- // can do nothing (such a JSON could be generated by an external application
- // as the policy for the service account). Inheriting the parent policy in
- // such a case, is a security issue. Ideally, we should not allow such
- // behavior, but for compatibility with the Console, we currently allow it.
- //
- // TODO:
- //
- // 1. fix console behavior and allow this inheritance for service accounts
- // created before a certain (TBD) future date.
- //
- // 2. do not allow empty statement policies for service accounts.
+ // service account should inherit parent policy. So when policy is empty in
+ // all fields we return hasSessionPolicy=false.
if subPolicy.Version == "" && subPolicy.Statements == nil && subPolicy.ID == "" {
hasSessionPolicy = false
return hasSessionPolicy, isAllowed
Source: GitHub Commit
Detection Methods for CVE-2025-62506
Indicators of Compromise
- Unexpected service account creation events in MinIO audit logs, particularly accounts created by other restricted service accounts
- Service accounts operating with privileges exceeding their intended policy restrictions
- Unusual access patterns to buckets or objects from previously restricted service accounts
- New service accounts created with no session policy attached when the parent account had restrictions
Detection Strategies
- Monitor MinIO audit logs for CreateServiceAccount API calls originating from existing service accounts or STS tokens
- Implement alerting on service account creation events where the calling principal has session policy restrictions
- Review IAM policy configurations for service accounts that may have been created to bypass restrictions
- Compare actual bucket access patterns against expected policy-defined access permissions
Monitoring Recommendations
- Enable comprehensive audit logging in MinIO to capture all IAM-related operations
- Set up alerts for privilege escalation patterns such as restricted accounts creating new unrestricted accounts
- Regularly audit service account permissions and compare against their session policies
- Monitor for anomalous object storage access patterns that deviate from expected user behavior
How to Mitigate CVE-2025-62506
Immediate Actions Required
- Upgrade MinIO to version RELEASE.2025-10-15T17-29-55Z or later immediately
- Audit all existing service accounts and STS tokens for unexpected privilege levels
- Review audit logs for any signs of exploitation or unauthorized service account creation
- Regenerate credentials for service accounts that may have been compromised
Patch Information
The vulnerability is fixed in MinIO version RELEASE.2025-10-15T17-29-55Z. The fix ensures proper validation of session policies by correctly returning hasSessionPolicy=false only when the policy is genuinely empty in all fields. Organizations should upgrade to this version or later to remediate the vulnerability. For more details, see the GitHub Security Advisory and the Pull Request #21642.
Workarounds
- Restrict network access to MinIO admin APIs to trusted networks only until patching is complete
- Disable service account self-management capabilities where possible through network-level controls
- Implement additional monitoring on IAM operations to detect exploitation attempts
- Consider rotating all service account credentials after upgrading to ensure no compromised accounts persist
# Configuration example
# Upgrade MinIO to the patched version
mc admin update myminio --yes
# Verify the MinIO version after upgrade
mc admin info myminio | grep Version
# Review existing service accounts for anomalies
mc admin user svcacct list myminio --user <username>
# Enable comprehensive audit logging
mc admin config set myminio audit_webhook:1 endpoint=https://audit-endpoint.example.com
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

