CVE-2025-11621

What it actually does

HashiCorp Vault and Vault Enterprise AWS Auth can fail to uniquely bind an IAM principal when bound_iam_principal (bound_iam_principal_arn) uses a role name that is not account-unique or includes a wildcard. Vault then treats a same-named IAM role in a different AWS account as the intended principal and issues a Vault token for the mapped auth role, bypassing intended AWS identity checks.

Why it matters to the business

An unauthorized party can obtain Vault tokens and read or mint secrets, cloud credentials, certificates, and encryption keys, enabling data exposure, downstream account takeover, and application outage. Vault is a common secrets backbone, so impact is organization-wide wherever AWS Auth is used with shared role names or wildcards. The issue is not in CISA KEV, has no public exploit maturity, and a low, flat EPSS (~0.49%), but CVSS 8.1 and ~one year since publication still warrant prompt patching of remaining unpatched clusters.

How an attack unfolds

An attacker finds a Vault cluster using AWS Auth and determines that a role is bound by a non-account-unique IAM role name or a wildcard ARN. They create or assume an IAM role with that same name in an AWS account they control, call STS to obtain valid AWS credentials, and submit those credentials to Vault’s AWS login API. Vulnerable matching logic accepts the foreign principal and returns a Vault token with the policies of the bound role. The attacker then uses the token to list and read secrets or generate dynamic credentials. No named threat actors or ransomware campaigns are associated with this CVE.

How to fix it

Upgrade Vault Community Edition to 1.21.0 or later, or Vault Enterprise to 1.21.0, 1.20.5, 1.19.11, or 1.16.27 (or later on the same streams). After upgrade, inventory every AWS auth role and replace wildcard or account-agnostic bound_iam_principal_arn values with fully qualified ARNs that include a specific AWS account ID. Prefer unique role names per account, restrict AWS Auth mount accessors and policies to least privilege, and rotate any secrets that could have been read if the misconfiguration was present. Source fix is also represented by commit 818ca8b3575ea937ca48b640baf35e1b2ede1833.

How to confirm the fix worked

Confirm running version is Community 1.21.0+ or Enterprise 1.21.0 / 1.20.5 / 1.19.11 / 1.16.27+. List AWS auth roles and verify every bound_iam_principal_arn is a fully qualified, non-wildcard ARN tied to an expected account. Attempt a login using an identically named IAM role from a non-bound AWS account in a controlled test and confirm the request is denied. Review Vault audit logs for successful aws logins whose account_id or client_arn is outside the approved account set.

Typical attack path

1. Locate a Vault cluster with the AWS auth method enabled (commonly path auth/aws).
2. Identify or infer bound IAM principal configuration that uses a shared role name across accounts or a wildcard ARN.
3. Create or assume an IAM role with the matching name in an attacker-controlled AWS account.
4. Obtain STS credentials for that role and submit them to Vault AWS login.
5. Receive a Vault client token mapped to the misbound auth role.
6. Use the token to read secrets, issue dynamic credentials, or perform other allowed Vault operations.

How to detect it

There is no public exploit or named actor activity; hunt for successful AWS Auth logins rather than malware artifacts. In Vault audit logs, search for successful requests to auth/aws/login (or custom AWS auth mount paths) where auth metadata account_id, client_arn, or canonical_arn is not in the approved AWS account list, or where inferred entity data does not match expected roles. Correlate those events with AWS CloudTrail AssumeRole, GetCallerIdentity, and sts:GetCallerIdentity activity from unexpected account IDs around the same timestamps. Review auth role config history and storage for bound_iam_principal_arn values containing '*' or role names without an account ID. Flag first-seen AWS account IDs authenticating to Vault and any subsequent secret-read or credential-issue operations under the issued token.

• auth/aws/login
• "type":"aws"
• bound_iam_principal_arn
• arn:aws:iam::*:role/
• canonical_arn
• client_arn
• inferred_entity_type
• sts:GetCallerIdentity
• eventName":"AssumeRole"

What your security team should do

• Patch all Vault Community and Enterprise clusters to the fixed versions above as a priority given CVSS 8.1 and secrets-manager blast radius, even though EPSS is low and the CVE is not KEV-listed.
• Immediately audit AWS auth roles for wildcard ARNs and role names reused across AWS accounts; tighten bindings before or during the upgrade window.
• Restrict which IAM principals can call Vault AWS login (VPC endpoints, IP allowlists, unique role names, and least-privilege Vault policies).
• Hunt historical Vault audit logs for successful AWS auth from unexpected AWS account IDs and rotate potentially exposed secrets if any are found.
• Add continuous config checks so new AWS auth roles cannot be created with wildcard or account-agnostic principal binds.