Listen to this Post
The OpenBao AWS auth method allows AWS entities (like IAM roles) to authenticate and receive a Vault token. It works by having an AWS entity sign a specific STS GetCallerIdentity request with its IAM credentials. This signed request is sent to OpenBao. OpenBao then forwards this signed request to the actual AWS STS service to validate the signature and retrieve the calling entity’s verified account ID (ARN), including the IAM role name.
The vulnerability (CVE-2025-59048) stems from how OpenBao’s `auth-aws` plugin, prior to version 0.1.1, matches the verified IAM role against its configured list of allowed roles. The plugin’s binding logic only considered the role name from the ARN (e.g., role/MyVaultAccessRole) and not the full unique ARN which includes the AWS account ID. When checking if the authenticated role was permitted, it would incorrectly match a role based solely on name similarity across different AWS accounts.
Therefore, if OpenBao was configured to trust the role arn:aws:iam::TRUSTED_ACCOUNT:role/MyVaultAccessRole, an attacker in an untrusted AWS account could create an IAM role named MyVaultAccessRole. By signing the authentication request with this rogue role’s credentials, the attacker would pass OpenBao’s validation. The plugin would receive the verified ARN arn:aws:iam::ATTACKER_ACCOUNT:role/MyVaultAccessRole, see the role name MyVaultAccessRole, and grant access as if it were the trusted role from TRUSTED_ACCOUNT, leading to full impersonation and unauthorized token issuance.
Platform: OpenBao
Version: < 0.1.1
Vulnerability: Role Impersonation
Severity: Critical
date: 10/23/2025
Prediction: 10/23/2025
What Undercode Say:
Check OpenBao AWS auth mount configuration bao path-help auth/aws/ List configured bound IAM roles bao read auth/aws/role/my-role Simulate vulnerable binding logic (pseudo-code) verified_arn="arn:aws:iam::ATTACKER_ACCOUNT:role/MyVaultAccessRole" configured_arn="arn:aws:iam::TRUSTED_ACCOUNT:role/MyVaultAccessRole" Flawed check (prior to fix): if [[ $(basename $verified_arn) == $(basename $configured_arn) ]]; then echo "Access granted - VULNERABLE" fi
How Exploit:
- Attacker creates IAM role in their AWS account, naming it identically to a trusted role in the target OpenBao configuration.
- Attacker uses the AWS CLI or SDK with the attacker role’s credentials to generate a signed sts:GetCallerIdentity request.
- Attacker submits this signed request to the OpenBao `/v1/auth/aws/login` endpoint.
- OpenBao validates the signature with AWS STS but then incorrectly matches only the role name.
- OpenBao issues a token with the privileges bound to the trusted role’s policy, granting unauthorized access.
Protection from this CVE:
- Immediately upgrade the `auth-aws` plugin to version 0.1.1 or later.
- The patch enforces binding on the full verified ARN, including the AWS account ID.
- Audit all configured `bound_iam_principal_id` entries for uniqueness across all potentially interacting AWS accounts.
- Implement AWS IAM condition keys (like
aws:PrincipalAccount) in OpenBao policies for additional validation.
Impact:
Unauthorized privilege escalation, data exposure, secret access, and policy bypass in multi-account AWS environments sharing IAM role names.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: nvd.nist.gov
Extra Source Hub:
Undercode
