CVE-2025-6037 Overview
CVE-2025-6037 affects HashiCorp Vault and Vault Enterprise. The TLS certificate authentication method fails to properly validate client certificates when a non-CA certificate is configured as a trusted certificate. An attacker with the ability to craft a malicious certificate can impersonate another authenticated user. The flaw maps to CWE-295: Improper Certificate Validation. HashiCorp addressed the issue in Vault Community Edition 1.20.1 and Vault Enterprise 1.20.1, 1.19.7, 1.18.12, and 1.16.23.
Critical Impact
Successful exploitation allows an attacker to impersonate another Vault user, gaining unauthorized access to secrets and policies bound to the impersonated identity.
Affected Products
- HashiCorp Vault Community Edition prior to 1.20.1
- HashiCorp Vault Enterprise prior to 1.20.1, 1.19.7, 1.18.12, and 1.16.23
- Vault deployments using the cert auth method with a non-CA certificate as a trusted certificate
Discovery Timeline
- 2025-08-01 - CVE-2025-6037 published to NVD
- 2026-06-17 - Last updated in NVD database
Technical Details for CVE-2025-6037
Vulnerability Analysis
Vault's TLS certificate authentication method (auth/cert) permits administrators to register a trusted certificate that clients must present during authentication. When the trusted certificate is a certificate authority (CA), Vault validates the client certificate chain and enforces constraints such as the Common Name (CN). When the configured trusted certificate is a leaf (non-CA) certificate, Vault does not correctly enforce the same identity validation checks against the presented client certificate.
This validation gap allows a caller to authenticate with a crafted certificate that Vault treats as a match for a role bound to another user's identity. The result is user impersonation within the Vault authorization model.
Root Cause
The root cause is improper certificate validation ([CWE-295]) in the cert auth backend. The code path for non-CA trusted certificates omits the identity attribute checks — including Common Name validation — that would otherwise bind the certificate to a specific principal. HashiCorp documents the issue in HashiCorp Security Advisory HCSEC-2025-18.
Attack Vector
Exploitation requires network access to a Vault endpoint that exposes the cert auth method and a Vault configuration where a non-CA certificate has been registered as trusted. The attacker must be able to craft a certificate whose fields align with the trusted certificate's expected attributes. The attack is remote over the network, but user interaction and elevated privileges to interact with the auth endpoint make exploitation conditional rather than trivial.
No public proof-of-concept exploit is available, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog.
Detection Methods for CVE-2025-6037
Indicators of Compromise
- Successful auth/cert logins from unexpected source IP addresses or client certificates not previously observed for the associated identity.
- Audit log entries showing certificate authentications where the presented certificate's serial number, fingerprint, or issuer differs from the historical baseline for that user.
- Access to secret paths or policies inconsistent with the normal behavior of the impersonated principal.
Detection Strategies
- Enable and centralize Vault audit device logging, then alert on auth/cert/login events that reference trusted certificates configured as non-CA.
- Correlate certificate fingerprints presented at login with an allowlist of known-good client certificates per identity.
- Baseline normal certificate-auth usage per role and alert on deviations in issuer, subject, or fingerprint.
Monitoring Recommendations
- Ship Vault audit logs to a centralized analytics platform and retain them for forensic review.
- Monitor the Vault configuration API for creation or modification of cert auth method entries that use leaf certificates.
- Track Vault version metadata across the fleet to identify hosts still running affected releases.
How to Mitigate CVE-2025-6037
Immediate Actions Required
- Upgrade to Vault Community Edition 1.20.1 or Vault Enterprise 1.20.1, 1.19.7, 1.18.12, or 1.16.23.
- Inventory all cert auth method configurations and identify any trusted certificate that is a non-CA (leaf) certificate.
- Rotate any secrets accessible through affected cert auth roles if impersonation cannot be ruled out.
- Review Vault audit logs for suspicious auth/cert logins since the affected configuration was introduced.
Patch Information
HashiCorp released fixes in Vault Community Edition 1.20.1 and Vault Enterprise 1.20.1, 1.19.7, 1.18.12, and 1.16.23. Full details are published in HashiCorp Security Advisory HCSEC-2025-18.
Workarounds
- Replace any non-CA trusted certificate in the cert auth method with a proper CA certificate and re-issue client certificates from that CA.
- Bind cert auth roles to specific certificate attributes such as allowed_common_names, allowed_dns_sans, allowed_uri_sans, or certificate serial numbers.
- Restrict network access to Vault listeners so that only trusted clients can reach the auth/cert endpoint.
# Example: harden a cert auth role by binding allowed identity attributes
vault write auth/cert/certs/web \
display_name=web \
policies=web-policy \
certificate=@ca.pem \
allowed_common_names="web.internal.example.com" \
allowed_dns_sans="web.internal.example.com" \
token_ttl=1h
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

