Page 3 of 40 results (0.009 seconds)

CVSS: 5.3EPSS: 0%CPEs: 6EXPL: 0

HashiCorp Vault and Vault Enterprise’s TLS certificate auth method did not initially load the optionally configured CRL issued by the role's CA into memory on startup, resulting in the revocation list not being checked if the CRL has not yet been retrieved. Fixed in 1.12.0, 1.11.4, 1.10.7, and 1.9.10. El método de autenticación de certificados TLS de HashiCorp Vault y Vault Enterprise no cargaba inicialmente la CRL configurada opcionalmente y emitida por la CA del rol en la memoria al iniciarse, resultando en que no se comprobara la lista de revocación si la CRL aún no era recuperada. Corregido en versiones 1.12.0, 1.11.4, 1.10.7 y 1.9.10 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. • https://discuss.hashicorp.com https://discuss.hashicorp.com/t/hcsec-2022-24-vaults-tls-cert-auth-method-only-loaded-crl-after-first-request/45483 https://security.netapp.com/advisory/ntap-20221201-0001 https://access.redhat.com/security/cve/CVE-2022-41316 https://bugzilla.redhat.com/show_bug.cgi?id=2135339 • CWE-295: Improper Certificate Validation •

CVSS: 9.1EPSS: 0%CPEs: 4EXPL: 0

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. Los clústeres de HashiCorp Vault Enterprise 1.7.0 a 1.9.7, 1.10.4 y 1.11.0 que utilizan Integrated Storage exponen un punto final de API no autenticado que podría ser abusado para anular el estado de votante de un nodo dentro de un clúster de Vault HA, introduciendo la posibilidad de una futura pérdida de datos o un fallo catastrófico. Corregido en Vault Enterprise 1.9.8, 1.10.5 y 1.11.1 • https://discuss.hashicorp.com https://discuss.hashicorp.com/t/hcsec-2022-15-vault-enterprise-does-not-verify-existing-voter-status-when-joining-an-integrated-storage-ha-node/42420 https://security.netapp.com/advisory/ntap-20220901-0011 • CWE-306: Missing Authentication for Critical Function •

CVSS: 6.5EPSS: 0%CPEs: 3EXPL: 0

Vault Enterprise clusters using the tokenization transform feature can expose the tokenization key through the tokenization key configuration endpoint to authorized operators with `read` permissions on this endpoint. Fixed in Vault Enterprise 1.9.4, 1.8.9 and 1.7.10. Los clústeres de Vault Enterprise usando la funcionalidad tokenization transform pueden exponer la clave de tokenización mediante el endpoint de configuración de la clave de tokenización a operadores autorizados con permisos "read" en este endpoint. Corregido en Vault Enterprise versiones 1.9.4, 1.8.9 y 1.7.10 • https://discuss.hashicorp.com https://discuss.hashicorp.com/t/hcsec-2022-08-vault-enterprise-s-tokenization-transform-configuration-endpoint-may-expose-transform-key/36599 •

CVSS: 6.8EPSS: 0%CPEs: 6EXPL: 0

In HashiCorp Vault and Vault Enterprise before 1.7.7, 1.8.x before 1.8.6, and 1.9.x before 1.9.1, clusters using the Integrated Storage backend allowed an authenticated user (with write permissions to a kv secrets engine) to cause a panic and denial of service of the storage backend. The earliest affected version is 1.4.0. En HashiCorp Vault y Vault Enterprise versiones anteriores a 1.7.7, 1.8.x anteriores a 1.8.6 y 1.9.x anteriores a 1.9.1, los clusters que usaban el backend de almacenamiento integrado permitían a un usuario autenticado (con permisos de escritura en un motor de secretos kv) causar un pánico y una denegación de servicio del backend de almacenamiento. La primera versión afectada es la 1.4.0 • https://discuss.hashicorp.com/t/hcsec2-21-33-vault-s-kv-secrets-engine-with-integrated-storage-exposed-to-authenticated-denial-of-service/33157 https://security.gentoo.org/glsa/202207-01 https://www.hashicorp.com/blog/category/vault •

CVSS: 6.5EPSS: 0%CPEs: 4EXPL: 0

HashiCorp Vault and Vault Enterprise 0.11.0 up to 1.7.5 and 1.8.4 templated ACL policies would always match the first-created entity alias if multiple entity aliases exist for a specified entity and mount combination, potentially resulting in incorrect policy enforcement. Fixed in Vault and Vault Enterprise 1.7.6, 1.8.5, and 1.9.0. Las políticas ACL templadas de HashiCorp Vault y Vault Enterprise 0.11.0 versiones hasta 1.7.5 y 1.8.4 siempre coincidían con el primer alias de entidad creado si presentaban varios alias de entidad para una combinación especificada de entidad y montaje, resultando potencialmente en una aplicación incorrecta de la política. Corregido en Vault y Vault Enterprise versiones 1.7.6, 1.8.5 y 1.9.0 A flaw was found in HashiCorp Vault. In affected versions of HashiCorp Vault and Vault Enterprise, templated ACL policies would always match the first-created entity alias if multiple entity aliases exist for a specified entity and mount combination, potentially resulting in incorrect policy enforcement. • https://discuss.hashicorp.com/t/hcsec-2021-30-vaults-templated-acl-policies-matched-first-created-alias-per-entity-and-auth-backend/32132 https://security.gentoo.org/glsa/202207-01 https://access.redhat.com/security/cve/CVE-2021-43998 https://bugzilla.redhat.com/show_bug.cgi?id=2028193 • CWE-732: Incorrect Permission Assignment for Critical Resource •