CVE-2025-6037Vault certificate-auth impersonation, public key not CN

What broke

Vault's TLS-certificate auth method identified the entity by the validated public key rather than the certificate identity (CN / SAN). A different certificate that reused the key authenticated as the original entity. CVSS 6.8. Fixed in 1.20.2.

Why it matters

Cert auth is how a lot of workloads log into Vault. Binding to the key instead of the name is the opposite of what strong certificate mapping taught Active Directory. The same mental model, two products.

What to do

• Upgrade, then rotate cert-auth roles so each entity has a unique key.
• Prefer binding to SAN URI / SPIFFE ID over "any cert with this key."

After you patch

A vault compromise is not one credential, it is every credential the vault held or could issue.

• Rotate everything in scope, including secrets the vault issued dynamically during the exposure window, because a lease that was valid then may still be valid now.
• Revoke active leases and tokens, then review the audit device log for reads you cannot attribute to a known workload.
• Rotate the vault's own credentials: unseal or recovery keys, root tokens, and any authentication backend configuration that could be used to re-enter.
• Rotate downstream credentials the vault brokered, cloud roles, database users, and PKI certificates, since the point of the vault is that it can mint them. See secrets rotation and what is secrets management.

Sources

• NVD: CVE-2025-6037