CVE-2025-59048: OpenBao AWS Plugin Auth Bypass Vulnerability

CVE-2025-59048 Overview

CVE-2025-59048 affects the OpenBao auth-aws plugin, which generates AWS access credentials based on Identity and Access Management (IAM) policies. Versions prior to 0.1.1 allow cross-account IAM role impersonation in the AWS auth method. An IAM role from an untrusted AWS account can authenticate by impersonating a role with an identical name in a trusted account. This grants unauthorized access to secrets governed by OpenBao policies bound to that role name. The flaw impacts any deployment of the auth-aws plugin running in multi-account AWS environments where IAM role names are not unique across accounts. The issue is tracked under [CWE-694] Use of Multiple Resources with Duplicate Identifier.

Critical Impact

Attackers controlling an IAM role in an untrusted AWS account can authenticate to OpenBao as a same-named role in a trusted account, breaking the AWS authentication trust boundary.

Affected Products

• OpenBao auth-aws plugin versions prior to 0.1.1
• OpenBao deployments using the AWS auth method in multi-account AWS environments
• Any OpenBao policy binding that references IAM role names not scoped by AWS account ID

Discovery Timeline

• 2025-10-23 - CVE-2025-59048 published to the National Vulnerability Database (NVD)
• 2025-12-05 - Last updated in NVD database

Technical Details for CVE-2025-59048

Vulnerability Analysis

The OpenBao auth-aws plugin authenticates clients by validating signed AWS Security Token Service (STS) requests and matching the returned IAM role identity against a configured OpenBao role binding. Before version 0.1.1, the plugin's internal client caching keyed AWS service clients by region and STS role only, omitting the AWS account ID. As a result, clients from different accounts that shared an IAM role name collapsed into a single cache entry. An attacker holding an IAM role named, for example, prod-app-role in an attacker-controlled account could authenticate against an OpenBao role bound to prod-app-role in the legitimate account. The plugin would issue tokens with the trusted role's policies. This violates the tenant isolation expected of the AWS auth method and exposes any secret the trusted role is authorized to read.

Root Cause

The root cause is an incomplete identifier used during client lookup and role resolution. The cached EC2 and IAM client maps were declared as map[string]map[string]*ec2.EC2 and map[string]map[string]*iam.IAM, indexed by region and STS role only. AWS account ID was not part of the composite key, so duplicate role names across accounts were treated as the same principal. The patch in commit 2a77af3 adds an additional map dimension so clients are now indexed by region, account ID, and STS role.

Attack Vector

Exploitation requires the attacker to create or control an IAM role in any AWS account that can reach the OpenBao server's AWS auth endpoint. The attacker names that role identically to a privileged role in a trusted account already bound in OpenBao. The attacker signs an sts:GetCallerIdentity request from their role and submits it to the OpenBao login API. The vulnerable plugin matches the role name without validating the account ID and issues a token tied to the trusted role's policies.

// Patch from auth/aws/backend.go (commit 2a77af3)
// Before: clients indexed by region and STS role only
// EC2ClientsMap map[string]map[string]*ec2.EC2
// IAMClientsMap map[string]map[string]*iam.IAM

// After: clients indexed by region, account ID, and STS role
EC2ClientsMap map[string]map[string]map[string]*ec2.EC2
IAMClientsMap map[string]map[string]map[string]*iam.IAM

// Source: https://github.com/openbao/openbao-plugins/commit/2a77af36834746ca6d3ac9bd1049154c84b3efae

Detection Methods for CVE-2025-59048

Indicators of Compromise

• OpenBao audit log entries showing successful auth/aws/login events for IAM roles whose AWS account ID does not match the account ID configured for the bound OpenBao role.
• AWS CloudTrail sts:GetCallerIdentity calls originating from IAM principals in unexpected accounts immediately preceding OpenBao token issuance.
• Issued OpenBao tokens with policies that do not align with the source IAM principal's actual AWS account.

Detection Strategies

• Correlate OpenBao audit logs with AWS CloudTrail events and flag any login where the AWS account ID in the STS response differs from the account ID expected for the bound OpenBao role.
• Inventory all IAM roles across every AWS account that can reach the OpenBao server and alert on duplicate role names spanning account boundaries.
• Review OpenBao role configurations under auth/aws/role/* for bound_iam_principal_arn values that do not pin a specific account ID.

Monitoring Recommendations

• Enable verbose OpenBao audit logging and forward both audit logs and AWS CloudTrail to a centralized analytics platform for cross-source correlation.
• Alert on first-seen account IDs presenting STS identities to the OpenBao AWS auth endpoint.
• Monitor for sudden spikes in auth/aws/login failures or successes against high-privilege roles, which may indicate enumeration of role names.

How to Mitigate CVE-2025-59048

Immediate Actions Required

• Upgrade the OpenBao auth-aws plugin to version 0.1.1 or later on every OpenBao node and restart the plugin to clear cached AWS clients.
• Audit all OpenBao AWS auth role bindings and replace role-name-only bindings with full role ARNs that include the AWS account ID.
• Rotate any OpenBao tokens, dynamic AWS credentials, and downstream secrets that may have been issued through the vulnerable code path.

Patch Information

The vulnerability is fixed in auth-aws plugin version 0.1.1. The fix is implemented in commit 2a77af36834746ca6d3ac9bd1049154c84b3efae, which extends the cached client maps to include AWS account ID as part of the composite key. See the OpenBao GitHub Security Advisory GHSA-jp7h-4f3c-9rc7 and the upstream patch commit for details.

Workarounds

• Guarantee that IAM role names are unique across every AWS account that can interact with the OpenBao environment.
• Audit existing IAM inventories for duplicate role names and rename or remove collisions before re-enabling the AWS auth method.
• Where possible, restrict the OpenBao AWS auth endpoint to trusted network paths so that only known accounts can reach it.

# Configuration example: bind OpenBao roles to full IAM principal ARNs
# (including the AWS account ID) rather than role names alone.
bao write auth/aws/role/prod-app-role \
    auth_type=iam \
    bound_iam_principal_arn="arn:aws:iam::111122223333:role/prod-app-role" \
    policies="prod-app-policy" \
    ttl=1h

# Verify the plugin version after upgrade
bao plugin info auth auth-aws