CVE-2025-6037

What it actually does

HashiCorp Vault's TLS certificate authentication method fails to correctly validate client certificates when a non-CA (leaf or otherwise non-certificate-authority) certificate is configured as the trusted certificate. In that configuration, certificate chain and identity checks are insufficient, so a crafted client certificate can be accepted as authentic. Successful abuse yields a valid Vault token bound to another identity, constituting an authentication bypass of the cert auth method rather than a remote code execution or data-at-rest cryptographic break.

Why it matters to the business

Vault commonly holds production credentials, API keys, certificates, and encryption keys. An impersonation success can expose those secrets and enable follow-on access to downstream systems. Real-world exposure is limited to instances that use cert auth AND configure a non-CA certificate as trusted, so blast radius is configuration-dependent rather than universal. This is not listed in CISA KEV, has no reported ransomware use, exploit maturity is none, and EPSS remains very low and flat (~0.0025). The issue has been public for well over a year, so unpatched Vaults with the vulnerable cert-auth pattern still represent avoidable secrets-management risk rather than an active mass-exploitation emergency.

How an attack unfolds

An attacker who can reach a Vault listener that has the TLS certificate auth method enabled, and that trusts a non-CA certificate, presents a malicious client certificate during cert-auth login. Because validation does not correctly constrain the presented certificate against that non-CA trust entry, Vault may map the request to another configured identity and issue a client token. The attacker then uses that token like a legitimate user—listing and reading secrets, using leases, or calling other allowed APIs—until the token expires or is revoked. No named threat actors or in-the-wild campaigns are associated with this CVE; abuse requires both network reachability to the auth endpoint and the specific non-CA trust misconfiguration.

How to fix it

Upgrade Vault Community Edition to 1.20.1 or later, or Vault Enterprise to 1.20.1, 1.19.7, 1.18.12, or 1.16.23 (source fix: git commit b403b1a27c8db6038ffefb296d7be0962e08039d). After upgrade, configure cert auth trusted certificates as CA certificates only; do not use leaf or other non-CA certificates as the trusted certificate. Recreate or rotate cert-auth roles that were bound to non-CA trust material, revoke outstanding tokens issued via cert auth during the vulnerable window, and restrict network access to the Vault API to trusted clients.

How to confirm the fix worked

Confirm the running Vault version is Community 1.20.1+ or Enterprise 1.20.1 / 1.19.7 / 1.18.12 / 1.16.23+. Inspect cert auth configuration and ensure every trusted certificate entry is a CA (basic constraints CA:TRUE), not a leaf. Attempting cert-auth login with a certificate that is not correctly chained to a configured CA should fail after the fix. Review Vault audit logs for cert-auth logins around the upgrade to ensure expected identities still authenticate and unexpected ones do not.

Typical attack path

1. Discover a Vault cluster that exposes the TLS certificate auth method
2. Determine that a cert auth role or trusted-certificate entry is a non-CA certificate rather than a proper CA
3. Identify a target identity (role, common name, or other cert-bound mapping) that the attacker wants to impersonate
4. Authenticate to the cert auth login path with a crafted client certificate that the flawed validator accepts
5. Receive a Vault client token associated with the impersonated identity
6. Use the token to read secrets, generate dynamic credentials, or invoke other policies allowed to that identity

How to detect it

There is no public exploit kit or named actor activity to hunt for. Detection is therefore configuration- and audit-log based. Enable and review Vault audit logs for cert-auth login requests (typically against the cert auth login path) looking for successful authentications from unexpected client IPs, unusual certificate common names or serials, identities that should not have logged in, or bursts of cert-auth success after previous failures. Compare issued token accessors and display names against known certificate inventories. On the host, confirm whether cert auth was configured with a non-CA trusted certificate before the patch. Network logs to the Vault API port showing client-certificate TLS handshakes from untrusted sources are supporting evidence, not proof of exploitation. Because exploit maturity is none, treat anomalous cert-auth token use and secret reads as the primary post-compromise signals.

• auth/cert/login
• "type":"request" combined with path containing auth/cert/login
• "auth_type":"cert"
• vault audit display_name or alias tied to unexpected certificate CN/serial on cert auth success
• Vault token creation metadata showing cert auth from atypical source IPs immediately followed by secret-read operations

What your security team should do

• Inventory all Vault Community and Enterprise clusters and prioritize those with the TLS certificate auth method enabled
• Patch to Community 1.20.1 or Enterprise 1.20.1, 1.19.7, 1.18.12, or 1.16.23 without waiting for KEV or EPSS movement
• Audit cert auth trusted-certificate entries and replace any non-CA trust configuration with proper CA-based trust
• Revoke cert-auth-issued tokens created before the upgrade and rotate secrets those identities could have read
• Ensure Vault audit logging is enabled and retain cert-auth login records for historical review
• Limit network exposure of the Vault API and require additional auth factors or policy constraints where cert auth is still used