Vault Enterprise
Monthly
Privilege escalation in HashiCorp Vault and Vault Enterprise allows an authenticated principal with delegated permissions to bypass explicit deny ACL rules by referencing a resource or policy name in non-canonical form, potentially reaching a protected resource or assigning a denied policy. Affected are Vault Community Edition before 2.1.2 and Vault Enterprise before 2.1.2, 1.21.12, 1.20.17, and 1.19.23, rated CVSS 3.1 7.2 (AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H). Exploitation requires an already high-privileged, delegated user (PR:H) operating in a policy model that depends on explicit deny rules, and no public exploit code or confirmed active exploitation was identified at time of analysis (no EPSS data was provided), so this is best handled as a defense-in-depth hardening fix rather than an emergency.
Arbitrary code execution on the Vault host is achievable in HashiCorp Vault and Vault Enterprise when a privileged operator restores a crafted Integrated Storage (Raft) snapshot in a deployment configured with Shamir seals and an external plugin directory, because stored plugin catalog entries are not consistently verified to reference binaries inside that configured directory (CWE-22 path traversal). The attacker must already hold the high privileges needed to restore a Raft snapshot (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H), and exploitation also depends on the non-default Shamir-seal-plus-external-plugin-directory configuration, so this is a genuinely serious but condition-gated vulnerability rather than a mass-exploitation threat; clusters using auto-unseal or without an external plugin directory are not affected by this path. No public exploit identified at time of analysis, and vendor-released fixes are available in Vault Community Edition 2.1.2 and Vault Enterprise 2.1.2, 1.21.12, 1.20.17, and 1.19.23.
Cross-namespace authorization bypass in HashiCorp Vault Enterprise's identity entity batch-delete endpoint allows an authenticated low-privileged caller in one namespace to permanently delete the storage backing of identity entities belonging to a completely separate namespace. Affected are all Vault Enterprise versions prior to the patched releases 2.0.4, 1.21.9, 1.20.14, and 1.19.20. No public exploit or CISA KEV listing has been identified at time of analysis, but the destructive, cross-tenant impact makes this a high-priority patch for any multi-namespace Vault Enterprise deployment.
HashiCorp Vault unauthenticated denial-of-service vulnerability allows remote attackers to block critical administrative operations by monopolizing the single operation slot for root token generation and rekey workflows. Affects all Vault Community and Enterprise versions prior to 2.0.0. No active exploitation confirmed (EPSS 3rd percentile), but attack is trivially automatable per CISA SSVC framework. HashiCorp released patches in Vault Community Edition 2.0.0 and Vault Enterprise 2.0.0.
Token leakage in HashiCorp Vault and Vault Enterprise (0.11.2 up to 2.0.0, 1.21.5, 1.20.10, and 1.19.16) occurs when an auth mount is configured to pass through the 'Authorization' header and that same header is used to authenticate to Vault; in this case Vault forwards the caller's Vault token onward to the auth plugin backend. An authenticated client's token is thereby exposed to a plugin backend that should never see it, enabling potential impersonation and unauthorized secret access. No public exploit identified at time of analysis, and EPSS exploitation probability is negligible (0.01%, 3rd percentile).
Server-side request forgery (SSRF) in HashiCorp Vault's PKI engine ACME validation allows unauthenticated remote attackers to send http-01 and tls-alpn-01 challenge requests to local network targets by controlling DNS responses, potentially disclosing sensitive information from internal services. The vulnerability affects Vault Community Edition before 2.0.0 and Vault Enterprise before 1.19.16, 1.20.10, or 1.21.5. HashiCorp has released patched versions; no public exploit code has been identified at the time of analysis.
HashiCorp Vault's KVv2 secrets engine allows authenticated users with glob-based policy access to delete secrets outside their authorization scope, causing denial-of-service across versions 0.10.0 through 1.x. The flaw stems from improper access control (CWE-288) in policy glob evaluation during delete operations. Exploitation requires valid Vault credentials with specific policy patterns but does not permit cross-namespace deletion or secret data exfiltration. Fixed in Vault Community Edition 2.0.0 and Vault Enterprise 2.0.0/1.21.5/1.20.10/1.19.16. No active exploitation confirmed (EPSS 0.01%), but CVSS 8.1 reflects high integrity and availability impact for authenticated attackers.
Cross-namespace privilege escalation in HashiCorp Vault Enterprise allows an authenticated token holding a specially crafted policy name containing path-traversal constructs to have its policy resolved against a different namespace - including the root namespace - thereby gaining capabilities granted by policies it should never reach. Only Vault Enterprise deployments with namespaces actually configured are exposed; Vault Community Edition does not implement namespaces and is explicitly not affected. Exploitation requires a valid token (CVSS PR:L, authenticated) and the resulting privilege gain is bounded by whatever policies exist in the traversed namespace, making this a moderate-priority privilege-escalation issue rather than a mass-exploitation threat - no public exploit code has been identified at time of analysis and no EPSS or KEV data was supplied.
HashiCorp Vault's PKI secrets engine ACME server, when running under the default directory policy, can issue certificates that contain identity claims the ACME challenges never validated, allowing an unauthenticated ACME client (CVSS vector PR:N/UI:N) to obtain a certificate for an identity it does not control and impersonate that identity toward systems that trust the affected Vault PKI mount. The issue is a configuration-dependent certificate-integrity flaw (CVSS 5.9, AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N) rather than an urgent remote-code or data-exposure bug: it requires a PKI mount with the ACME server enabled under the default directory policy and relying systems that actually trust certificates issued by that mount, otherwise the unverified identity has no effect. HashiCorp addressed it in Vault Community Edition 2.1.2 and Vault Enterprise 2.1.2, 1.21.12, 1.20.17, and 1.19.23; no public exploit code and no confirmed active exploitation were identified at time of analysis, and no EPSS score was supplied in the available data.
Privilege escalation in HashiCorp Vault allows authenticated low-privileged users to traverse outside their authorized secret paths by injecting forward-slash characters into identity values referenced by templated ACL policy paths. Both Vault Community and Enterprise editions from version 0.11.0 through 2.0.3 are affected across all platforms. No public exploit code or active exploitation is confirmed at time of analysis; however, the high confidentiality and integrity impact make this a priority for any organization using identity-based templated ACL policies.
Plugin directory guard bypass in HashiCorp Vault and Vault Enterprise allows a highly privileged, authenticated attacker to read files outside the intended audit plugin directory via path traversal. Exploitation requires network access, high-privilege credentials, and the use of the legacy file audit path option - a non-default configuration. Fixed versions are 2.0.1, 1.21.6, 1.20.11, and 1.19.17; no public exploit or active exploitation (CISA KEV) has been identified at time of analysis.
Privilege escalation in HashiCorp Vault and Vault Enterprise allows an authenticated principal with delegated permissions to bypass explicit deny ACL rules by referencing a resource or policy name in non-canonical form, potentially reaching a protected resource or assigning a denied policy. Affected are Vault Community Edition before 2.1.2 and Vault Enterprise before 2.1.2, 1.21.12, 1.20.17, and 1.19.23, rated CVSS 3.1 7.2 (AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H). Exploitation requires an already high-privileged, delegated user (PR:H) operating in a policy model that depends on explicit deny rules, and no public exploit code or confirmed active exploitation was identified at time of analysis (no EPSS data was provided), so this is best handled as a defense-in-depth hardening fix rather than an emergency.
Arbitrary code execution on the Vault host is achievable in HashiCorp Vault and Vault Enterprise when a privileged operator restores a crafted Integrated Storage (Raft) snapshot in a deployment configured with Shamir seals and an external plugin directory, because stored plugin catalog entries are not consistently verified to reference binaries inside that configured directory (CWE-22 path traversal). The attacker must already hold the high privileges needed to restore a Raft snapshot (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H), and exploitation also depends on the non-default Shamir-seal-plus-external-plugin-directory configuration, so this is a genuinely serious but condition-gated vulnerability rather than a mass-exploitation threat; clusters using auto-unseal or without an external plugin directory are not affected by this path. No public exploit identified at time of analysis, and vendor-released fixes are available in Vault Community Edition 2.1.2 and Vault Enterprise 2.1.2, 1.21.12, 1.20.17, and 1.19.23.
Cross-namespace authorization bypass in HashiCorp Vault Enterprise's identity entity batch-delete endpoint allows an authenticated low-privileged caller in one namespace to permanently delete the storage backing of identity entities belonging to a completely separate namespace. Affected are all Vault Enterprise versions prior to the patched releases 2.0.4, 1.21.9, 1.20.14, and 1.19.20. No public exploit or CISA KEV listing has been identified at time of analysis, but the destructive, cross-tenant impact makes this a high-priority patch for any multi-namespace Vault Enterprise deployment.
HashiCorp Vault unauthenticated denial-of-service vulnerability allows remote attackers to block critical administrative operations by monopolizing the single operation slot for root token generation and rekey workflows. Affects all Vault Community and Enterprise versions prior to 2.0.0. No active exploitation confirmed (EPSS 3rd percentile), but attack is trivially automatable per CISA SSVC framework. HashiCorp released patches in Vault Community Edition 2.0.0 and Vault Enterprise 2.0.0.
Token leakage in HashiCorp Vault and Vault Enterprise (0.11.2 up to 2.0.0, 1.21.5, 1.20.10, and 1.19.16) occurs when an auth mount is configured to pass through the 'Authorization' header and that same header is used to authenticate to Vault; in this case Vault forwards the caller's Vault token onward to the auth plugin backend. An authenticated client's token is thereby exposed to a plugin backend that should never see it, enabling potential impersonation and unauthorized secret access. No public exploit identified at time of analysis, and EPSS exploitation probability is negligible (0.01%, 3rd percentile).
Server-side request forgery (SSRF) in HashiCorp Vault's PKI engine ACME validation allows unauthenticated remote attackers to send http-01 and tls-alpn-01 challenge requests to local network targets by controlling DNS responses, potentially disclosing sensitive information from internal services. The vulnerability affects Vault Community Edition before 2.0.0 and Vault Enterprise before 1.19.16, 1.20.10, or 1.21.5. HashiCorp has released patched versions; no public exploit code has been identified at the time of analysis.
HashiCorp Vault's KVv2 secrets engine allows authenticated users with glob-based policy access to delete secrets outside their authorization scope, causing denial-of-service across versions 0.10.0 through 1.x. The flaw stems from improper access control (CWE-288) in policy glob evaluation during delete operations. Exploitation requires valid Vault credentials with specific policy patterns but does not permit cross-namespace deletion or secret data exfiltration. Fixed in Vault Community Edition 2.0.0 and Vault Enterprise 2.0.0/1.21.5/1.20.10/1.19.16. No active exploitation confirmed (EPSS 0.01%), but CVSS 8.1 reflects high integrity and availability impact for authenticated attackers.
Cross-namespace privilege escalation in HashiCorp Vault Enterprise allows an authenticated token holding a specially crafted policy name containing path-traversal constructs to have its policy resolved against a different namespace - including the root namespace - thereby gaining capabilities granted by policies it should never reach. Only Vault Enterprise deployments with namespaces actually configured are exposed; Vault Community Edition does not implement namespaces and is explicitly not affected. Exploitation requires a valid token (CVSS PR:L, authenticated) and the resulting privilege gain is bounded by whatever policies exist in the traversed namespace, making this a moderate-priority privilege-escalation issue rather than a mass-exploitation threat - no public exploit code has been identified at time of analysis and no EPSS or KEV data was supplied.
HashiCorp Vault's PKI secrets engine ACME server, when running under the default directory policy, can issue certificates that contain identity claims the ACME challenges never validated, allowing an unauthenticated ACME client (CVSS vector PR:N/UI:N) to obtain a certificate for an identity it does not control and impersonate that identity toward systems that trust the affected Vault PKI mount. The issue is a configuration-dependent certificate-integrity flaw (CVSS 5.9, AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N) rather than an urgent remote-code or data-exposure bug: it requires a PKI mount with the ACME server enabled under the default directory policy and relying systems that actually trust certificates issued by that mount, otherwise the unverified identity has no effect. HashiCorp addressed it in Vault Community Edition 2.1.2 and Vault Enterprise 2.1.2, 1.21.12, 1.20.17, and 1.19.23; no public exploit code and no confirmed active exploitation were identified at time of analysis, and no EPSS score was supplied in the available data.
Privilege escalation in HashiCorp Vault allows authenticated low-privileged users to traverse outside their authorized secret paths by injecting forward-slash characters into identity values referenced by templated ACL policy paths. Both Vault Community and Enterprise editions from version 0.11.0 through 2.0.3 are affected across all platforms. No public exploit code or active exploitation is confirmed at time of analysis; however, the high confidentiality and integrity impact make this a priority for any organization using identity-based templated ACL policies.
Plugin directory guard bypass in HashiCorp Vault and Vault Enterprise allows a highly privileged, authenticated attacker to read files outside the intended audit plugin directory via path traversal. Exploitation requires network access, high-privilege credentials, and the use of the legacy file audit path option - a non-default configuration. Fixed versions are 2.0.1, 1.21.6, 1.20.11, and 1.19.17; no public exploit or active exploitation (CISA KEV) has been identified at time of analysis.