Where
AND
-Infinity
0
Severity
5.7
AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:N/A:N

Vault and Vault Enterprise’s (“Vault”) login MFA rate limits could be bypassed and TOTP tokens could be reused. Fixed in Vault Community Edition 1.20.1 and Vault Enterprise 1.20.1, 1.19.7, 1.18.12, and 1.16.23.

First published (updated )
Severity
8.1
AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N

Vault and Vault Enterprise’s (“Vault”) ldap auth method may not have correctly enforced MFA if usernameasalias was set to true and a user had multiple CNs that are equal but with leading or trailing spaces. Fixed in Vault Community Edition 1.20.2 and Vault Enterprise 1.20.2, 1.19.8, 1.18.13, and 1.16.24.

First published (updated )
Severity
7.5
EPSS
0.04%
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Vault and Vault Enterprise did not properly handle requests originating from unauthorized IP addresses when the TCP listener option, proxyprotocolbehavior, was set to denyunauthorized. When receiving a request from a source IP address that was not listed in proxyprotocolauthorizedaddrs, the Vault API server would shut down and no longer respond to any HTTP requests, potentially resulting in denial of service.

While this bug also affected versions of Vault up to 1.17.1 and 1.16.5, a separate regression in those release series did not allow Vault operators to configure the denyunauthorized option, thus not allowing the conditions for the denial of service to occur.

Fixed in Vault and Vault Enterprise 1.17.2, 1.16.6, and 1.15.12

1 / 2
Source: GitHub
First published (updated )
Severity
5.3
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

A flaw was found in HashiCorp Vault and Vault Enterprise. Vault’s TLS certificate auth method did not initially load the optionally-configured CRL issued by the role’s Certificate Authority (CA) into memory on startup, resulting in the revocation list not being checked if the CRL has not yet been retrieved.

1 / 3
First published (updated )
Severity
9.1
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

An issue was discovered in HashiCorp Vault and Vault Enterprise before 1.11.3. A vulnerability in the Identity Engine was found where, in a deployment where an entity has multiple mount accessors with shared alias names, Vault may overwrite metadata to the wrong alias due to an issue with checking the proper alias assigned to an entity. This may allow for unintended access to key/value paths using that metadata in Vault.

First published (updated )
Severity
9.1
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H

HashiCorp Vault Enterprise 1.7.0 through 1.9.7, 1.10.4, and 1.11.0 clusters using Integrated Storage expose an unauthenticated API endpoint that could be abused to override the voter status of a node within a Vault HA cluster, introducing potential for future data loss or catastrophic failure. Fixed in Vault Enterprise 1.9.8, 1.10.5, and 1.11.1.

First published (updated )
Severity
5.3
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

HashiCorp Vault and Vault Enterprise from 1.10.0 to 1.10.2 did not correctly configure and enforce MFA on login after server restarts. This affects the Login MFA feature introduced in Vault and Vault Enterprise 1.10.0 and does not affect the separate Enterprise MFA feature set. Fixed in 1.10.3.

First published (updated )

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203