Skip to content
KitploitKITPLOIT
ToolsBlog
Submit
ToolsBlog
Submit

Hacking, PenTest, and Cybersecurity Tools for Your Security Arsenal!

Kitploit is a directory of hacking, cybersecurity, and pentesting tools. Discover the latest project updates to find vulnerabilities, analyze systems, automate testing, and strengthen your security.

··Feeds·Contact·Privacy·© 2026 Kitploit

Tool Directory

Categories

View all categories
Loading categories
CVE-2025-62506 — 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. | Kitploit
Tools/GitHubGitHub/yoshino-s/cve-2025-62506
Privilege EscalationVulnerability AnalysisExploitationPenetration TestingCloud Security
GitHubyoshino-s/cve-2025-62506

CVE-2025-62506

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.

View Repository
10 months agoNot yet reviewed

Most Popular

View all →

Discover the most used tools by our community.

Explore all tools

Browse our collection of tools

View all tools →
Share

CVE-2025-62506 Vulnerability Verification Script

中文

Overview

This repository contains a verification script for CVE-2025-62506, a privilege escalation vulnerability in MinIO service accounts and STS (Security Token Service) accounts.

Vulnerability Description

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.

Technical Details

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.

Attack Scenario

  1. An administrator creates a service account or STS account with a restricted inline policy (e.g., access only to bucket1 and bucket2)
  2. The restricted account attempts to create a new service account for itself without specifying any policy restrictions
  3. Due to the bypass, the new service account is created with full parent privileges instead of being restricted by the inline policy
  4. The attacker now has escalated privileges beyond the intended restrictions

Impact

  • Attack Complexity: LOW - Exploitation requires only valid credentials for a restricted service/STS account
  • Confidentiality: HIGH - Attackers can access buckets and objects beyond their intended restrictions
  • Integrity: HIGH - Attackers can modify, delete, or create objects outside their authorized scope
  • Availability: NONE - Does not directly impact service availability

CVSS Score

8.1 (High) - CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N

Affected Versions

All versions prior to RELEASE.2025-10-15T17-29-55Z

Fixed Version

RELEASE.2025-10-15T17-29-55Z

References

  • GitHub Security Advisory
  • Fix Commit
  • Fix PR

Verification Script

The verify_cve_2025_62506.py script tests whether your MinIO installation is vulnerable to CVE-2025-62506.

Prerequisites

  • Python 3.7+
  • MinIO server running (can be started with the provided docker-compose.yml)
  • Required Python packages: minio

Installation

  1. Start MinIO server:
root@kitploit:~
docker-compose up -d
  1. Install dependencies:
root@kitploit:~
pip install minio

Script Workflow

The verification script follows these steps:

Step 1: Create Test Buckets

  • Creates three test buckets: bucket1, bucket2, bucket3
  • These buckets are used to test account access permission restrictions

Step 2: Create Restricted Policy

  • Creates an IAM policy that only allows access to bucket1 and bucket2
  • Policy details:
    • Allowed Actions: s3:* (all S3 operations)
    • Allowed Resources: bucket1/*, bucket2/*
    • Denied Resources: All other buckets (including bucket3)

Step 3: Create Restricted Service Account

  • Creates a service account with the restricted policy applied as an inline policy
  • Account details:
    • Access Key: restricted
    • Secret Key: restricted123
    • Policy: Inline restricted policy (bucket1 and bucket2 only)
    • Expected Behavior: Can only access specified buckets

Step 4: Test Restricted Account Access

  • Uses the restricted account to list buckets
  • Verifies that permissions are properly restricted
  • Expected Result: Can only see bucket1 and bucket2

Step 5: Attempt Privilege Escalation (Vulnerability Test)

  • Uses the restricted account to attempt creating a new service account
  • The new account is created without specifying a policy (should inherit parent restrictions)
  • Vulnerability Test: If creation succeeds, attempts to use the new account to access unauthorized resources (bucket3)
  • Secure Behavior: Creation should fail with permission denied error

Cleanup

  • Removes all test service accounts
  • Removes the test policy
  • Removes all test buckets and their contents

Usage

  1. Ensure MinIO is running:
root@kitploit:~
docker-compose up -d
  1. Run the verification script:
root@kitploit:~
python verify_cve_2025_62506.py

Expected Output

Vulnerable System

root@kitploit:~
🚀 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
============================================================

Secure System

root@kitploit:~
🚀 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
============================================================

Mitigation

  1. Upgrade MinIO: Update to version RELEASE.2025-10-15T17-29-55Z or higher
  2. Audit Service Accounts: Review all service accounts created by non-admin accounts
  3. Revoke Suspicious Accounts: Delete any service accounts that may have been created through exploitation
  4. Review Access Logs: Check for unauthorized access to sensitive buckets

License

This verification script is provided as-is for security testing purposes.

Download Tool