CVE-2024-2048

What it actually does

The TLS certificate authentication method incorrectly validates client certificates when a non-CA (leaf) certificate is configured as the trusted certificate. A crafted client certificate can be accepted as valid, bypassing certificate-based authentication and yielding a client token bound to the cert-auth mount and role policies, with high impact on confidentiality, integrity, and availability of stored secrets.

Why it matters to the business

Unauthorized parties could obtain secrets, encryption keys, and other credentials from the secrets manager, enabling follow-on access to applications and infrastructure. This is a high-severity authentication bypass (CVSS 8.1) but is not in CISA KEV, has no known in-the-wild use or ransomware association, and has a low, stable EPSS (~0.45%). Exploitation also requires an uncommon configuration (trusting a leaf certificate rather than a CA) and high attack complexity. Unpatched Vault 1.14.x/1.15.x and unpatched OpenBao remain overdue for upgrade nearly three years after disclosure.

How an attack unfolds

An unauthenticated attacker who can reach the secrets-manager HTTP API determines that certificate authentication is enabled and that a non-CA certificate is configured as trusted. They present a crafted client TLS certificate that the flawed validator incorrectly accepts. The service issues a normal authentication token as if a legitimate client had connected. The attacker then uses that token under the bound policy to list and read secrets or perform other authorized operations. No public exploit is known; success depends on network reachability plus the uncommon leaf-certificate trust setting.

How to fix it

Upgrade HashiCorp Vault to 1.15.5 or 1.14.10 or later, or upgrade OpenBao to a build that includes commit 700fe3f27ab1f0ec39ce20c36f6d9d97c9fe6ac3. Reconfigure the certificate auth method to trust only CA certificates (not leaf certificates). Restrict network access to the API, apply least-privilege policies on cert-auth roles, and rotate tokens and secrets that may have been issued via certificate auth while the vulnerable configuration was in place.

How to confirm the fix worked

Confirm the running version is Vault 1.15.5+, Vault 1.14.10+, or an OpenBao build containing commit 700fe3f27ab1f0ec39ce20c36f6d9d97c9fe6ac3. Inspect certificate auth method configuration and verify trusted material is a CA (basicConstraints CA:TRUE), not a leaf certificate. Confirm only legitimately issued client certificates authenticate and that unexpected certificates are rejected. Review audit logs for certificate-auth successes from the period the vulnerable configuration was active.

Typical attack path

1. Reach the Vault or OpenBao HTTP API over the network
2. Identify that the TLS certificate auth method is enabled
3. Determine that a non-CA leaf certificate is configured as the trusted certificate
4. Present a crafted client certificate that the flawed validator accepts
5. Receive a valid authentication token
6. Use the token to read secrets and perform operations allowed by the bound policy

How to detect it

There is no public exploit and no named threat-actor activity, so look for abuse of normal certificate-auth flows rather than unique malware. Enable and review Vault/OpenBao audit logs for auth/cert/login successes, especially from unexpected source IPs, unusual certificate subjects or common names, or clients that do not match known inventory. Correlate successful cert-auth tokens with subsequent secret-read and lease operations. Check configuration history and snapshots for a non-CA certificate configured as trusted on the cert auth method. Network logs to the API on the cert-login path from unknown clients are also relevant. Absence of those events does not prove non-exploitation if audit logging was off.

• auth/cert/login
• /v1/auth/cert/login
• "type":"cert"
• auth.cert.login
• request.path":"auth/cert/login

What your security team should do

• Patch Vault to 1.15.5 / 1.14.10+ or OpenBao to commit 700fe3f27ab1f0ec39ce20c36f6d9d97c9fe6ac3 immediately if certificate auth is enabled
• Inventory cert-auth mounts and remove any trusted leaf (non-CA) certificates; trust only CAs
• Restrict network exposure of the API and require mTLS or other controls in front of it
• Hunt audit logs for historical auth/cert/login successes and unexpected certificate subjects or display names
• Rotate tokens, leases, and high-value secrets that could have been obtained via cert auth before the patch
• Tighten cert-auth role policies to least privilege and enable detailed audit logging if it is not already on