The official vault docker images before 0.11.6 contain a blank password for a root user. System using the vault docker container deployed by affected versions of the docker image may allow a remote attacker to achieve root access with a blank password.

HashiCorp Vault and Vault Enterprise 1.4.0 and 1.4.1, when configured with the GCP Secrets Engine, may incorrectly generate GCP Credentials with the default time-to-live lease duration instead of the engine-configured setting. This may lead to generated GCP credentials being valid for longer than intended. Fixed in 1.4.2.

HashiCorp Vault and Vault Enterprise 1.0 before 1.5.4 have Incorrect Access Control.

A privileged Vault operator within the root namespace with write permission to {{sys/audit}} may obtain code execution on the underlying host if a plugin directory is set in Vault’s configuration. Fixed in Vault Community Edition 1.20.1 and Vault Enterprise 1.20.1, 1.19.7, 1.18.12, and 1.16.23.

HashiCorp Vault and Vault Enterprise versions 0.11.0 through 1.3.3 may, under certain circumstances, have existing nested-path policies grant access to Namespaces created after-the-fact. Fixed in 1.3.4.

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.

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.

Vault Community, Vault Enterprise (“Vault”) Azure Auth method did not correctly validate the claims in the Azure-issued token, resulting in the potential bypass of the boundlocations parameter on login. Fixed in Vault Community Edition 1.19.1 and Vault Enterprise 1.19.1, 1.18.7, 1.17.14, 1.16.18.

If a Vault auth mount is configured to pass through the "Authorization" header, and the "Authorization" header is used to authenticate to Vault, Vault forwarded the Vault token to the auth plugin backend. Fixed in 2.0.0, 1.21.5, 1.20.10, and 1.19.16.

Vault’s PKI engine’s ACME validation did not reject local targets when issuing http-01 and tls-alpn-01 challenges. This may lead to these requests being sent to local network targets, potentially leading to information disclosure. Fixed in Vault Community Edition 2.0.0 and Vault Enterprise 2.0.0, 1.21.5, 1.20.10, and 1.19.16.

A flaw was found in Vault and Vault Enterprise (“Vault”). In the affected versions of Vault, with the AWS Auth Method configured and under certain circumstances, the values relied upon by Vault to validate AWS IAM identities and roles may be manipulated and bypass authentication.

A vulnerability was identified in Vault and Vault Enterprise (“Vault”) such that, with the GCP Auth Method configured and under certain circumstances, the values relied upon by Vault to validate Google Compute Engine (GCE) VMs may be manipulated and authentication bypassed.

https://www.hashicorp.com/blog/category/vault/ https://github.com/hashicorp/vault/blob/master/CHANGELOG.md#151 http://packetstormsecurity.com/files/159479/Hashicorp-Vault-GCP-IAM-Integration-Authentication-Bypass.html

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.

Vault and Vault Enterprise's ("Vault") AWS Auth method may be susceptible to authentication bypass if the role of the configured boundprincipaliam is the same across AWS accounts, or uses a wildcard. This vulnerability 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.

An authenticated user with access to a kvv2 path through a policy containing a glob may be able to delete secrets they were not authorized to read or write, resulting in denial-of-service. This vulnerability did not allow a malicious user to delete secrets across namespaces, nor read any secret data. Fixed in Vault Community Edition 2.0.0 and Vault Enterprise 2.0.0, 1.21.5, 1.20.10, and 1.19.16.

HashiCorp Vault and Vault Enterprise 1.8.x through 1.8.4 may have an unexpected interaction between glob-related policies and the Google Cloud secrets engine. Users may, in some situations, have more privileges than intended, e.g., a user with read permission for the /gcp/roleset/ path may be able to issue Google Cloud service account credentials.

HashiCorp Vault before 1.0.0 writes the master key to the server log in certain unusual or misconfigured scenarios in which incorrect data comes from the autoseal mechanism without an error being reported.

A flaw was found in the Hashicorp vault. When using the Vault and Vault Enterprise approle auth method, any authenticated user with access to the /auth/approle/role/:rolename/secret-id-accessor/destroy endpoint can destroy the secret ID of another role by providing the secret ID accessor.

A flaw was found in hashicorp/vault. Google Cloud secrets engine did not preserve existing Google Cloud IAM Conditions upon creating or updating role sets. Fixed in Vault 1.13.0.

https://github.com/advisories/GHSA-86c6-3g63-5w64

Vault and Vault Enterprise did not properly validate the JSON Web Token (JWT) role-bound audience claim when using the Vault JWT auth method. This may have resulted in Vault validating a JWT the audience and role-bound claims do not match, allowing an invalid login to succeed when it should have been rejected.

This vulnerability, CVE-2024-5798, was fixed in Vault and Vault Enterprise 1.17.0, 1.16.3, and 1.15.9

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

A malicious user may submit a specially-crafted complex payload that otherwise meets the default request size limit which results in excessive memory and CPU consumption of Vault. This may lead to a timeout in Vault’s auditing subroutine, potentially resulting in the Vault server to become unresponsive. This vulnerability, CVE-2025-6203, is fixed in Vault Community Edition 1.20.3 and Vault Enterprise 1.20.3, 1.19.9, 1.18.14, and 1.16.25.

Vault and Vault Enterprise ("Vault") are vulnerable to an unauthenticated denial of service when processing JSON payloads. This occurs due to a regression from a previous fix for [+HCSEC-2025-24+|https://discuss.hashicorp.com/t/hcsec-2025-24-vault-denial-of-service-though-complex-json-payloads/76393]  which allowed for processing JSON payloads before applying rate limits. This vulnerability, CVE-2025-12044, is fixed in Vault Community Edition 1.21.0 and Vault Enterprise 1.16.27, 1.19.11, 1.20.5, and 1.21.0.

Vault is vulnerable to a denial-of-service condition where an unauthenticated attacker can repeatedly initiate or cancel root token generation or rekey operations, occupying the single in-progress operation slot. This prevents legitimate operators from completing these workflows. This vulnerability, CVE-2026-5807, is fixed in Vault Community Edition 2.0.0 and Vault Enterprise 2.0.0.

HashiCorp Vault and Vault Enterprise before 1.3.6, and 1.4.2 before 1.4.2, insert Sensitive Information into a Log File. The vulnerability is affecting github.com/hashicorp/vault/command Go package.

HashiCorp Vault and Vault Enterprise 1.5.1 and newer, under certain circumstances, may exclude revoked but unexpired certificates from the CRL. Fixed in 1.5.8, 1.6.4, and 1.7.1.

HashiCorp Vault and Vault Enterprise Cassandra integrations (storage backend and database secrets engine plugin) did not validate TLS certificates when connecting to Cassandra clusters. Fixed in 1.6.4 and 1.7.1

HashiCorp Vault Enterprise 0.11.0 through 1.3.1 fails, in certain circumstances, to revoke dynamic secrets for a mount in a deleted namespace. Fixed in 1.3.2.

HashiCorp vault-action (aka Vault GitHub Action) before 2.2.0 allows attackers to obtain sensitive information from log files because a multi-line secret was not correctly registered with GitHub Actions for log masking.

HashiCorp Vault Enterprise 1.6.0 & 1.6.1 allowed the remove-peer raft operator command to be executed against DR secondaries without authentication. Fixed in 1.6.2.