CVE-2024-2048: High Auth Bypass in HashiCorp Vault Cert Auth

CVE-2024-2048 is a high severity authentication bypass in HashiCorp Vault and Vault Enterprise, scored CVSS 8.1. The TLS certificate auth method did not fully validate client certificates when a non-CA certificate was the trusted one. HashiCorp fixed it in Vault 1.15.5 and 1.14.10, so upgrade and review how your cert auth roles are configured.

What's affected

HashiCorp's bulletin HCSEC-2024-05 lists Vault and Vault Enterprise up to 1.15.4 and 1.14.9 as affected. The fixes are in Vault 1.15.5 and 1.14.10, and newer releases.

Only one configuration is in scope: the TLS certificate auth method with a non-CA certificate set as the trusted certificate. Vault's cert auth supports trusted certificates signed by a certificate authority as well as non-CA certificates. Vault relies on Go's TLS libraries to validate client certificates, plus extra checks in its own code, and the bulletin says it was the non-CA case that was insufficiently validated. The weakness class is CWE-295, improper certificate validation.

The NVD record scores the issue 8.1 (High) with the vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. The attack complexity is high because, according to the bulletin, the attacker would need out-of-band access to information about the public trusted certificate. The HashiCorp bulletin text we read does not give its own severity rating, so the NVD score is the only one we can quote.

One conflict worth knowing about. The record's affected products also list OpenBao, a Vault fork. The HashiCorp bulletin covers only Vault and Vault Enterprise, and we did not retrieve any OpenBao advisory. If you run OpenBao, check that project's own security notices instead of assuming a version mapping.

How to check if you're exposed

First, find your version. From a machine with access to the server:

vault version
vault status

Anything below 1.15.5 on the 1.15 line, or below 1.14.10 on the 1.14 line, is in the affected range. Versions older than 1.14 are not named in the bulletin, so treat them as a reason to plan an upgrade and read the upgrade notes.

Next, check whether the cert auth method is even enabled and how it is set up:

vault auth list
vault list auth/cert/certs

The first command shows whether a cert/ mount exists. The second lists the certificate roles. For each role, look at the trusted certificate and ask whether it is a CA certificate or an ordinary leaf certificate. You can inspect the certificate file with OpenSSL and read the Basic Constraints line:

openssl x509 -in trusted.pem -noout -text

A certificate that says CA:FALSE, or that has no CA flag, is a non-CA certificate. If you trust one of those in a cert auth role, you are in the configuration the bulletin describes.

Vault is usually run as a service, so also check where it appears in your build artifacts. The free in-browser dependency scan at gold.safeguard.sh/scan can flag Go modules and vendored copies of Vault libraries in your own projects, though it does not replace checking the servers you actually run.

What to do now

1. Upgrade each affected Vault or Vault Enterprise server to 1.15.5, 1.14.10 or a newer release. Read the Upgrading Vault guidance for version specific notes first.
2. Inventory every cert auth role and note which ones use a non-CA certificate as the trusted certificate. Those are the exposed ones.
3. Where practical, move those roles to certificates issued by a CA, so the trust decision does not rest on a single leaf certificate.
4. Review audit logs for cert auth logins you do not recognize, especially from unfamiliar source addresses.
5. If you run OpenBao, read that project's security notices, because the HashiCorp bulletin does not speak for it.
6. Record the upgrade in your change log and re-run your authentication tests after the move.

Why it matters

Authentication bypass bugs matter because Vault sits at the center of secret handling. A login that should have been refused can lead to tokens, and tokens lead to secrets. The cause here is a validation gap in one code path. Vault checked client certificates with Go's TLS libraries and its own extra checks, but for non-CA trusted certificates those checks were not sufficient. It is a good reminder that trust configuration choices, such as pinning a leaf certificate instead of a CA, change which code runs.

CVE-2024-2048 is not on the CISA Known Exploited Vulnerabilities list, and none of the sources we read report exploitation in the wild. The bulletin describes the risk as conditional on the attacker holding out-of-band knowledge of the trusted public certificate, which is why the CVSS complexity is high. That is not a reason to wait. Public certificates are not secret by design, and the fix is a routine upgrade.

Try it yourself

See how continuous monitoring flags a component the day a new advisory lands, instead of at the next scheduled scan.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• HashiCorp bulletin HCSEC-2024-05
• Gold entry for CVE-2024-2048
• NetApp advisory ntap-20240524-0009 is referenced by the record but was not retrieved.

Last reviewed: 19 October 2026.