Miggo Logo

CVE-2025-59048: OpenBao AWS Plugin Vulnerable to Cross-Account IAM Role Impersonation in AWS Auth Method

8.1

CVSS Score
3.1

Basic Information

EPSS Score
-
Published
10/23/2025
Updated
10/23/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/openbao/openbao-pluginsgo<= 0.1.00.1.1

Vulnerability Intelligence
Miggo AIMiggo AI

Miggo AIRoot Cause Analysis

The vulnerability is a cross-account impersonation flaw within the auth-aws plugin of OpenBao, identified as GHSA-jp7h-4f3c-9rc7. The root cause is a defective caching mechanism for AWS clients (EC2 and IAM). The analysis of the patch commit 2a77af36834746ca6d3ac9bd1049154c84b3efae reveals that the client caches were indexed only by region and STS role name, critically omitting the AWS Account ID.

This created a scenario where, if two AWS accounts (one trusted, one untrusted) had IAM roles with identical names, the system could not distinguish between them in the cache. An authentication attempt from the untrusted account's role could be served a cached client belonging to the trusted account's role, leading to unauthorized access to secrets and other resources.

The primary vulnerable functions are aws.(*backend).clientEC2 and aws.(*backend).clientIAM, which were responsible for retrieving clients from this flawed cache. The patch rectifies this by restructuring the cache maps (EC2ClientsMap and IAMClientsMap) to include the accountID as part of the key, thereby ensuring that clients for roles with the same name but in different accounts are cached separately.

Additionally, the aws.(*backend).stsRoleForAccount function was modified to prevent it from implicitly using the default account's role for other accounts, adding another layer of defense against this type of impersonation.

Vulnerable functions

aws.(*backend).clientEC2
auth/aws/client.go
The `clientEC2` function was vulnerable because it retrieved cached EC2 clients using a key that only consisted of the region and the STS role name (`stsRole`). It did not include the AWS Account ID. This flaw allowed an authentication request from an untrusted AWS account, using an IAM role with the same name as a role in a trusted account, to receive the cached client of the trusted role. This resulted in cross-account impersonation, granting unauthorized access.
aws.(*backend).clientIAM
auth/aws/client.go
Similar to `clientEC2`, the `clientIAM` function used a flawed caching mechanism for IAM clients. The cache key was missing the AWS Account ID, leading to a cache collision when two different accounts used IAM roles with the same name. An attacker could exploit this to obtain a cached IAM client for a role in a trusted account, leading to unauthorized access and privilege escalation.
aws.(*backend).stsRoleForAccount
auth/aws/client.go
This function determines which STS role to use for a given account. Prior to the patch, it would implicitly allow the authentication flow to proceed using the default account's context if no specific STS configuration was found for the provided `accountID`. This behavior was a contributing factor to the impersonation vulnerability, as it allowed the subsequent call to the flawed client caching functions (`clientEC2` and `clientIAM`) to occur. The patch introduces a strict check to fail explicitly if a non-default account lacks an STS configuration.

WAF Protection Rules

WAF Rule

### Imp**t T*is is * *ross-***ount imp*rson*tion vuln*r**ility in t** `*ut*-*ws` plu*in. T** vuln*r**ility *llows *n I*M rol* *rom *n untrust** *WS ***ount to *ut**nti**t* *y imp*rson*tin* * rol* wit* t** **s*m* n*m*** in * trust** ***ount, l***in* t

Reasoning

T** vuln*r**ility is * *ross-***ount imp*rson*tion *l*w wit*in t** `*ut*-*ws` plu*in o* Op*n**o, i**nti*i** *s **S*-jp**-****-*r**. T** root **us* is * *****tiv* ****in* m****nism *or *WS *li*nts (*** *n* I*M). T** *n*lysis o* t** p*t** *ommit `*****
CVE-2025-59048: OpenBao AWS Role Impersonation | Miggo