
Verification script for CVE-2025-62506, a privilege escalation vulnerability in MinIO service accounts, testing if restricted accounts can bypass inline policies to create unrestricted accounts.
This repository contains a verification script for CVE-2025-62506, a privilege escalation vulnerability in MinIO service accounts and STS (Security Token Service) accounts.
CVE-2025-62506 is a privilege escalation vulnerability that allows restricted service accounts and STS accounts to bypass their inline policy restrictions when performing "own" account operations, specifically when creating new service accounts for the same user.
The vulnerability exists in the IAM policy validation logic in cmd/iam.go. When validating session policies for restricted accounts performing operations on their own account (such as creating service accounts), the code incorrectly relied on the DenyOnly argument.
The DenyOnly flag is used to allow accounts to perform actions related to their own account by only checking if the action is explicitly denied. However, when a session policy (sub-policy) is present, the system should validate that the action is actually allowed by the session policy, not just that it isn't denied.
8.1 (High) - CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
All versions prior to RELEASE.2025-10-15T17-29-55Z
RELEASE.2025-10-15T17-29-55Z
The verify_cve_2025_62506.py script tests whether your MinIO installation is vulnerable to CVE-2025-62506.
docker-compose.yml)miniodocker-compose up -d
pip install minio
The verification script follows these steps:
bucket1, bucket2, bucket3bucket1 and bucket2s3:* (all S3 operations)bucket1/*, bucket2/*bucket3)restrictedrestricted123bucket1 and bucket2bucket3)docker-compose up -d
python verify_cve_2025_62506.py
🚀 CVE-2025-62506 Vulnerability Verification Script
============================================================
📋 Script Description:
This script tests for the MinIO service account privilege escalation vulnerability (CVE-2025-62506)
The vulnerability allows restricted service accounts to bypass inline policies when creating new accounts
============================================================
📦 Step 1: Create Test Buckets
Creating three test buckets: bucket1, bucket2, bucket3
Used to test account access permission restrictions
----------------------------------------
✅ Created bucket: bucket1
✅ Created bucket: bucket2
✅ Created bucket: bucket3
🔒 Step 2: Create Restricted Policy
Creating a policy that only allows access to bucket1 and bucket2
This policy will be applied to the restricted service account
----------------------------------------
✅ Created policy: restricted-policy
📋 Policy Permissions:
- Allowed Actions: s3:* (all S3 operations)
- Allowed Resources: bucket1/*, bucket2/*
- Denied Resources: All other buckets
👤 Step 3: Create Restricted Service Account
Creating a service account with the restricted policy above
This account can only access bucket1 and bucket2
----------------------------------------
✅ Created service account: restricted
📋 Account Permissions:
- Access Key: restricted
- Policy: Inline restricted policy (bucket1 and bucket2 only)
- Expected Behavior: Can only access specified buckets
🧪 Step 4: Test Restricted Account Access
Using the restricted account to list buckets, verifying permissions are properly restricted
Expected Result: Can only see bucket1 and bucket2
----------------------------------------
✅ Restricted account correctly limited to allowed buckets
Accessible buckets: ['bucket1', 'bucket2']
⚡ Step 5: Attempt Privilege Escalation (Vulnerability Test)
Using the restricted account to attempt creating a new service account
New account without specified policy should inherit parent restrictions
Vulnerability: Restricted account may bypass policy to create unrestricted new accounts
----------------------------------------
✅ Created service account: newroot
📋 Attempting to use new service account to access unauthorized bucket3
⬆️ Attempting to upload object to bucket3 to verify permissions
⬇️ Attempting to list objects to verify permissions
Found object: test-object
❌ VULNERABLE: Restricted account successfully created new service account
New account permissions: Unrestricted (inherited full parent permissions)
This indicates CVE-2025-62506 vulnerability is present!
🧹 Cleaning up test resources...
----------------------------------------
✅ Removed service account: restricted
✅ Removed service account: newroot
✅ Removed policy: restricted-policy
✅ Removed bucket: bucket1
✅ Removed bucket: bucket2
✅ Removed bucket: bucket3
============================================================
📊 Verification Results
============================================================
❌ RESULT: VULNERABLE - CVE-2025-62506 is present
💡 Recommendation: Upgrade immediately to patched version RELEASE.2025-10-15T17-29-55Z or higher
🔗 Reference: https://github.com/minio/minio/security/advisories/GHSA-jjjj-jwhf-8rgr
============================================================
🚀 CVE-2025-62506 Vulnerability Verification Script
============================================================
📋 Script Description:
This script tests for the MinIO service account privilege escalation vulnerability (CVE-2025-62506)
The vulnerability allows restricted service accounts to bypass inline policies when creating new accounts
============================================================
📦 Step 1: Create Test Buckets
Creating three test buckets: bucket1, bucket2, bucket3
Used to test account access permission restrictions
----------------------------------------
✅ Created bucket: bucket1
✅ Created bucket: bucket2
✅ Created bucket: bucket3
🔒 Step 2: Create Restricted Policy
Creating a policy that only allows access to bucket1 and bucket2
This policy will be applied to the restricted service account
----------------------------------------
✅ Created policy: restricted-policy
📋 Policy Permissions:
- Allowed Actions: s3:* (all S3 operations)
- Allowed Resources: bucket1/*, bucket2/*
- Denied Resources: All other buckets
👤 Step 3: Create Restricted Service Account
Creating a service account with the restricted policy above
This account can only access bucket1 and bucket2
----------------------------------------
✅ Created service account: restricted
📋 Account Permissions:
- Access Key: restricted
- Policy: Inline restricted policy (bucket1 and bucket2 only)
- Expected Behavior: Can only access specified buckets
🧪 Step 4: Test Restricted Account Access
Using the restricted account to list buckets, verifying permissions are properly restricted
Expected Result: Can only see bucket1 and bucket2
----------------------------------------
✅ Restricted account correctly limited to allowed buckets
Accessible buckets: ['bucket1', 'bucket2']
⚡ Step 5: Attempt Privilege Escalation (Vulnerability Test)
Using the restricted account to attempt creating a new service account
New account without specified policy should inherit parent restrictions
Vulnerability: Restricted account may bypass policy to create unrestricted new accounts
----------------------------------------
✅ SECURE: Restricted account failed to create new service account
Error: Permission correctly denied
Details: Access Denied.
🧹 Cleaning up test resources...
----------------------------------------
✅ Removed service account: restricted
✅ Removed policy: restricted-policy
✅ Removed bucket: bucket1
✅ Removed bucket: bucket2
✅ Removed bucket: bucket3
============================================================
📊 Verification Results
============================================================
✅ RESULT: SECURE - CVE-2025-62506 is patched
🎉 Your MinIO version has this vulnerability patched
============================================================
This verification script is provided as-is for security testing purposes.