CVSS: 6.5EPSS: 0%CPEs: 6EXPL: 0CVE-2023-0665 – Vault PKI Issuer Endpoint Did Not Correctly Authorize Access to Issuer Metadata
https://notcve.org/view.php?id=CVE-2023-0665
HashiCorp Vault's PKI mount issuer endpoints did not correctly authorize access to remove an issuer or modify issuer metadata, potentially resulting in denial of service of the PKI mount. This bug did not affect public or private key material, trust chains or certificate issuance. Fixed in Vault 1.13.1, 1.12.5, and 1.11.9. A flaw was found in the Hashicorp vault. Vault’s PKI mount issuer endpoints did not correctly authorize access to remove an issuer or modify issuer metadata, potentially resulting in a denial of service of the PKI mount. • https://discuss.hashicorp.com/t/hcsec-2023-11-vault-s-pki-issuer-endpoint-did-not-correctly-authorize-access-to-issuer-metadata/52079/1 https://security.netapp.com/advisory/ntap-20230526-0008 https://access.redhat.com/security/cve/CVE-2023-0665 https://bugzilla.redhat.com/show_bug.cgi?id=2182981 • CWE-285: Improper Authorization •
CVSS: 5.0EPSS: 0%CPEs: 6EXPL: 0CVE-2023-25000 – Vault Vulnerable to Cache-Timing Attacks During Seal and Unseal Operations
https://notcve.org/view.php?id=CVE-2023-25000
HashiCorp Vault's implementation of Shamir's secret sharing used precomputed table lookups, and was vulnerable to cache-timing attacks. An attacker with access to, and the ability to observe a large number of unseal operations on the host through a side channel may reduce the search space of a brute force effort to recover the Shamir shares. Fixed in Vault 1.13.1, 1.12.5, and 1.11.9. A flaw was found in the Hashicorp vault. This flaw allows an attacker with access to and the ability to observe a large number of unseal operations on the host through a side channel to reduce the search space of a brute-force effort to recover the Shamir shares. • https://discuss.hashicorp.com/t/hcsec-2023-10-vault-vulnerable-to-cache-timing-attacks-during-seal-and-unseal-operations/52078 https://security.netapp.com/advisory/ntap-20230526-0008 https://access.redhat.com/security/cve/CVE-2023-25000 https://bugzilla.redhat.com/show_bug.cgi?id=2182972 • CWE-203: Observable Discrepancy CWE-208: Observable Timing Discrepancy •
CVSS: 8.1EPSS: 0%CPEs: 6EXPL: 0CVE-2023-24999 – Vault Fails to Verify if the AppRole SecretID Belongs to Role During a Destroy Operation
https://notcve.org/view.php?id=CVE-2023-24999
HashiCorp Vault and Vault Enterprise’s approle auth method allowed any authenticated user with access to an approle destroy endpoint to destroy the secret ID of any other role by providing the secret ID accessor. This vulnerability is fixed in Vault 1.13.0, 1.12.4, 1.11.8, 1.10.11 and above. 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/:role_name/secret-id-accessor/destroy endpoint can destroy the secret ID of another role by providing the secret ID accessor. • https://discuss.hashicorp.com/t/hcsec-2023-07-vault-fails-to-verify-if-approle-secretid-belongs-to-role-during-a-destroy-operation/51305 https://security.netapp.com/advisory/ntap-20230505-0001 https://access.redhat.com/security/cve/CVE-2023-24999 https://bugzilla.redhat.com/show_bug.cgi?id=2177844 • CWE-863: Incorrect Authorization •
CVSS: 5.3EPSS: 0%CPEs: 6EXPL: 0CVE-2022-41316 – vault: insufficient certificate revocation list checking
https://notcve.org/view.php?id=CVE-2022-41316
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: 6EXPL: 0CVE-2022-40186 – vault: Vault Entity Alias Metadata May Leak Between Aliases With The Same Name Assigned To The Same Entity
https://notcve.org/view.php?id=CVE-2022-40186
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. Se ha detectado un problema en HashiCorp Vault y Vault Enterprise versiones anteriores a 1.11.3. Se ha encontrado una vulnerabilidad en el Motor de Identidades por la que, en una implementación en la que una entidad presenta varios accesos de montaje con nombres de alias compartidos, Vault puede sobrescribir los metadatos en el alias incorrecto debido a un problema de comprobación del alias correcto asignado a una entidad. • https://discuss.hashicorp.com https://discuss.hashicorp.com/t/hcsec-2022-18-vault-entity-alias-metadata-may-leak-between-aliases-with-the-same-name-assigned-to-the-same-entity/44550 https://security.netapp.com/advisory/ntap-20221111-0008 https://access.redhat.com/security/cve/CVE-2022-40186 https://bugzilla.redhat.com/show_bug.cgi?id=2181405 •