How severe is CVE-2025-62506?

CVE-2025-62506 has a CVSS score of 8.1/10, rated HIGH. Immediate patching is strongly recommended.

Which packages are affected by CVE-2025-62506?

CVE-2025-62506 affects the following packages: github.com/minio/minio (Go). Ecosystems affected: Go.

How do I fix CVE-2025-62506?

Update github.com/minio/minio to 0.0.0-20251015170045-c1a49490c78e or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2025-62506 is resolved across your whole dependency graph.

How do I detect CVE-2025-62506 in my Go dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/minio/minio, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

How do I mitigate CVE-2025-62506 if there is no patch (or I can't update yet)?

Close the privilege gap rather than the entry point: audit which accounts, roles and service identities can reach the affected operation, drop the component to the least privilege it actually needs, and review file and directory permissions created by earlier installs — a default left in place is what makes this reachable.

Is CVE-2025-62506 actively exploited in the wild?

No public exploit code has been indexed for CVE-2025-62506 yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

What is the EPSS score for CVE-2025-62506?

CVE-2025-62506 has an EPSS (Exploit Prediction Scoring System) score of 0.6%, placing it in the 47th percentile of all CVEs. EPSS is maintained by FIRST.org and estimates the probability that a vulnerability will be exploited in the wild within the next 30 days. This score indicates relatively lower exploitation probability, though the CVSS severity should still guide your patching priority.

What type of vulnerability is CVE-2025-62506?

CVE-2025-62506 is classified as CWE-863 (CWE-863). This weakness type describe the underlying flaw category, which helps determine the potential impact and the right class of mitigation.

When was CVE-2025-62506 published, and has it been updated?

CVE-2025-62506 was published on October 16, 2025 and was last updated on October 28, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

🐹

🐹 Go

Not in CISA KEV

HIGH severity

CVE-2025-62506 — minio

HIGHFix: minio/minio@c1a4949

CVE-2025-62506 is a high-severity (CVSS 8.1) CWE-863 vulnerability in github.com/minio/minio. A fix is available for github.com/minio/minio — see the affected versions and patch details below.

MinIO vulnerable to privilege escalation via session policy bypass in service accounts and STS

Also known asGHSA-jjjj-jwhf-8rgrGO-2025-4034

Published

Oct 16, 2025

Updated

Oct 28, 2026

Affected

1 pkg

Patched

1 / 1

Exploits

None indexed

Exploitation data as of Nov 7, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for CVE-2025-62506.

EPSS Exploitation Probability

via FIRST.org ↗

0.6%probability of exploitation in next 30 days

Lower Risk+0.01%

Lower risk than most CVEs47th percentile — riskier than 47% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

Where this sits among everything scored

Real-World Exposure

1 pkg affected

🐹github.com/minio/minio

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

Summary

A privilege escalation vulnerability allows service accounts and STS (Security Token Service) accounts with restricted session policies to bypass their inline policy restrictions when performing "own" account operations, specifically when creating new service accounts for the same user.

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

An administrator creates a service account or STS account with a restricted inline policy (e.g., access only to bucket1 and bucket2)
The restricted account attempts to create a new service account for itself without specifying any policy restrictions
Due to the bypass, the new service account is created with full parent privileges instead of being restricted by the inline policy
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

Patches

Fixed in PR https://github.com/minio/minio/pull/21642 Commit: c1a49490c78e9c3ebcad86ba0662319138ace190

Install the release

go install -v github.com/minio/[email protected]

Workarounds

No workarounds available. You can upgrade to the latest version immediately.

Mitigation Steps

Upgrade MinIO: Update to the latest version containing the fix
Audit Service Accounts: Review all service accounts created by non-admin accounts
Revoke Suspicious Accounts: Delete any service accounts that may have been created through exploitation
Review Access Logs: Check for unauthorized access to sensitive buckets

Resources

Fix PR: https://github.com/minio/minio/pull/21642
Affected code: cmd/iam.go (functions: isAllowedBySessionPolicyForServiceAccount, isAllowedBySessionPolicy)

Affected Packages

1 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
🐹Go	`github.com/minio/minio`	all versions	0.0.0-20251015170045-c1a49490c78e`go get github.com/minio/minio@v0.0.0-20251015170045-c1a49490c78e`

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/minio/minio, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/minio/minio to 0.0.0-20251015170045-c1a49490c78e or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2025-62506 is resolved across your whole dependency graph.
Workarounds
Close the privilege gap rather than the entry point: audit which accounts, roles and service identities can reach the affected operation, drop the component to the least privilege it actually needs, and review file and directory permissions created by earlier installs — a default left in place is what makes this reachable.

Frequently Asked Questions

### Summary A privilege escalation vulnerability allows service accounts and STS (Security Token Service) accounts with restricted session policies to bypass their inline policy restrictions when performing "own" account operations, specifically when creating new service accounts for the same user. ### 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` f