Miggo Logo

CVE-2025-62506: MinIO is Vulnerable to Privilege Escalation via Session Policy Bypass in Service Accounts and STS

8.1

CVSS Score
3.1

Basic Information

EPSS Score
-
Published
10/16/2025
Updated
10/16/2025
KEV Status
No
Technology
TechnologyGo

Technical Details

CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
Package NameEcosystemVulnerable VersionsFirst Patched Version
github.com/minio/miniogo< 0.0.0-20251015170045-c1a49490c78e0.0.0-20251015170045-c1a49490c78e

Vulnerability Intelligence
Miggo AIMiggo AI

Miggo AIRoot Cause Analysis

The vulnerability allows a service account or an STS account with a restrictive session policy to create a new service account without those restrictions, effectively escalating its privileges. This is caused by a flaw in the IAM policy validation logic within MinIO.

The analysis of the patch c1a49490c78e9c3ebcad86ba0662319138ace190 reveals that the root cause lies in the handling of the DenyOnly flag within the isAllowedBySessionPolicyForServiceAccount and isAllowedBySessionPolicy functions located in cmd/iam.go.

For operations that a user performs on their own account (e.g., creating a service account for themselves), the DenyOnly flag is set to true. This typically means the operation is allowed as long as there isn't an explicit "Deny" rule. However, when a restrictive session policy is in place, the logic should have been to check if the action is explicitly allowed by that session policy. Instead, the vulnerable code continued to honor the DenyOnly=true flag, checking only for denials, which are unlikely to be present in a restrictive allow policy. This effectively bypassed the session policy.

The fix involves explicitly setting DenyOnly = false within these two functions whenever a session policy is being evaluated. This forces the subsequent policy check (subPolicy.IsAllowed) to validate that the action is explicitly permitted by the session policy, closing the privilege escalation vector. Therefore, these two functions are the direct locations of the vulnerability and would be on the execution path when this vulnerability is triggered.

Vulnerable functions

isAllowedBySessionPolicyForServiceAccount
cmd/iam.go
This function was vulnerable because it incorrectly validated session policies for service accounts performing "own" account operations. It respected the `DenyOnly` argument from the caller, which could be `true` for self-service operations. This allowed bypassing the session policy check, as the check would only look for explicit denials, not for explicit allowances. An attacker with a restricted service account could exploit this to create a new, unrestricted service account, thus escalating privileges. The patch fixes this by forcing `DenyOnly` to `false` when a session policy is present, ensuring the action is explicitly allowed by the policy.
isAllowedBySessionPolicy
cmd/iam.go
Similar to `isAllowedBySessionPolicyForServiceAccount`, this function was vulnerable when handling STS (Security Token Service) accounts. It failed to correctly validate session policies for STS accounts during "own" account operations by incorrectly using the `DenyOnly` argument. This allowed an attacker with a restricted STS token to create a service account with privileges beyond the scope of the STS session policy. The patch corrects this by setting `DenyOnly` to `false` when a session policy exists, enforcing a strict check that the action is allowed.

WAF Protection Rules

WAF Rule

### Summ*ry * privil*** *s**l*tion vuln*r**ility *llows s*rvi** ***ounts *n* STS (S**urity Tok*n S*rvi**) ***ounts wit* r*stri*t** s*ssion poli*i*s to *yp*ss t**ir inlin* poli*y r*stri*tions w**n p*r*ormin* "own" ***ount op*r*tions, sp**i*i**lly w**n

Reasoning

T** vuln*r**ility *llows * s*rvi** ***ount or *n STS ***ount wit* * r*stri*tiv* s*ssion poli*y to *r**t* * n*w s*rvi** ***ount wit*out t*os* r*stri*tions, *****tiv*ly *s**l*tin* its privil***s. T*is is **us** *y * *l*w in t** I*M poli*y v*li**tion lo