Bulletin ID: HCSEC-2025-30
Affected Products / Versions: Vault Community Edition 0.6.0 up to 1.20.4, fixed in 1.21.0.
Vault Enterprise 0.6.0 up to 1.20.4, 1.19.10, 1.18.15, and 1.16.26. fixed in 1.21.0, 1.20.5, 1.19.11, and 1.16.27.
Publication Date: October 23, 2025
Summary
Vault and Vault Enterprise’s (“Vault”) AWS Auth method may be susceptible to authentication bypass if the role of the configured bound_principal_iam is the same across AWS accounts, or uses a wildcard. This vulnerability, CVE-2025-11621, is fixed in Vault Community Edition 1.21.0 and Vault Enterprise 1.21.0, 1.20.5, 1.19.11, and 1.16.27.
Background
Vault’s AWS auth method provides an automated mechanism to retrieve a Vault token for IAM principals and AWS EC2 instances. The logic checks for the STS role’s existence in AWS utilizing the default account. However, since this check does not validate the accountID, an attacker can bypass this logic.
Details
Vault’s AWS Auth method maintains a cache of active AWS clients, but this cache did not validate the account ID when querying the cache. If accountID metadata is solely referenced in the bound_principal_arn with wildcards and a user has an active session, an attacker with an identical role name (or one that collides based on the wildcards) within a different account can authenticate. This can lead to sensitive data exposure and potential opportunities for additional privilege escalation.
A similar issue exists within Vault’s EC2 authentication method, where the corresponding cache lookup validates only ami_id but not the account ID. This may allow for cross-account privilege escalation, where an attacker can bypass intended authorization controls by authenticating from a different account.
Remediation
Customers using Vault should evaluate the risk associated with this issue and consider upgrading to Vault Community Edition 1.21.0 or Vault Enterprise 1.21.0, 1.20.5, 1.19.11, and 1.16.27.
See Vault’s Upgrading documentation for general guidance on this process.
Acknowledgement
This issue was identified by Pavlos Karakalidis who reported it to HashiCorp.
We deeply appreciate any effort to coordinate disclosure of security vulnerabilities. For information about security at HashiCorp and the reporting of security vulnerabilities, please see https://hashicorp.com/security.