CVE-2024-2660

What it actually does

The Vault TLS certificates authentication method failed to correctly validate Online Certificate Status Protocol (OCSP) responses whenever one or more OCSP sources were configured. As a result, certificate revocation status was not reliably enforced, so a client presenting a revoked or otherwise OCSP-invalid TLS certificate could still be treated as authenticated. Successful abuse yields the confidentiality, integrity, and availability impact of an authenticated Vault identity (secrets read/write and policy-bound operations) without a valid, non-revoked certificate. Exploitation requires adjacent-network reachability, high privileges, and high attack complexity; there is no change of scope.

Why it matters to the business

If Vault is used as the secrets and identity backbone and TLS-certificate auth with OCSP is enabled, a revoked certificate that should have been blocked can still unlock secrets, credentials, and policy-bound operations. That can lead to unauthorized access to application secrets, lateral movement into dependent systems, and integrity loss of stored configuration. Urgency is moderated: the issue is not listed in CISA KEV, is not associated with ransomware campaigns, has no known exploit maturity, and EPSS remains very low and flat (~0.003 over 30 days). Adjacent-network access and high privileges are required, so internet-wide mass exploitation is unlikely. Organizations that rely on OCSP to enforce certificate revocation for machine identities should still treat this as a high-priority patch for those Vault clusters. The advisory is long-published, so remaining unpatched estates represent avoidable residual risk rather than a zero-day emergency.

How an attack unfolds

An attacker who already has high privileges and adjacent-network access to a Vault listener that uses the TLS certificates auth method with OCSP configured presents a TLS client certificate that should fail OCSP checks (for example, a revoked certificate). Because OCSP responses were not validated correctly, Vault may accept the certificate and issue a Vault token bound to that identity. The attacker then uses that token under existing policies to read or modify secrets. No public exploit or named threat-actor campaign is associated with this CVE; abuse depends on already having a relevant certificate, network position, and privileges, plus OCSP being enabled on the auth method.

How to fix it

Upgrade HashiCorp Vault to 1.16.0 or later, or Vault Enterprise to 1.16.1, 1.15.7, or 1.14.11 (or any later patched release on those trains). After upgrade, restart Vault servers so the corrected TLS certificates auth method OCSP validation is loaded. Confirm that certs auth methods that intend to enforce revocation still have OCSP sources configured as designed. Until patched, reduce exposure by restricting adjacent-network access to Vault listeners (network segmentation, allow-lists), reviewing and tightening policies attached to certificate-mapped identities, rotating or fully revoking high-value machine certificates at the CA and in Vault, and monitoring certs-auth logins from unexpected subjects. Disabling OCSP is not a substitute for patching if revocation checking is a control requirement.

How to confirm the fix worked

Inventory Vault and Vault Enterprise nodes and compare running versions to 1.16.0 (Vault) or 1.16.1 / 1.15.7 / 1.14.11 (Enterprise). Confirm the process binary/build matches a fixed release. For each certs auth method, document whether OCSP sources are configured (those paths were the vulnerable code). After upgrade, authenticate with a known-good certificate and verify success, and verify that a certificate that is revoked or OCSP-invalid is rejected. Review auth method configuration and listener TLS settings for unintended OCSP bypass. Re-scan or re-query version endpoints and configuration as part of change control.

Typical attack path

1. Identify a Vault or Vault Enterprise cluster that exposes the TLS certificates auth method with one or more OCSP sources configured and that has not been upgraded to a fixed release.
2. Obtain adjacent-network access to the Vault API/listener and a client certificate that should be rejected by OCSP (typically a revoked cert for an identity that still has useful policies).
3. Authenticate to the certs auth method; flawed OCSP response handling may cause Vault to accept the certificate and return a token.
4. Use the issued token within the mapped policies to read secrets, generate dynamic credentials, or change Vault data.
5. Operate under the stolen identity until the token expires or is revoked; optionally persist by minting additional tokens if policy allows.

How to detect it

There is no public exploit, named actor, or KEV/ransomware association, so hunt for abuse of the certs auth path rather than a unique malware signature. Review Vault audit logs for successful login via the TLS certificates auth method (auth/cert) especially where the presented certificate serial or subject is revoked at the issuing CA or fails OCSP. Correlate those successes with subsequent secret reads, token creates, and policy changes. Compare client source addresses against expected machine-identity networks (adjacent-network requirement). Check Vault version and build in logs/metrics for unpatched nodes. On the CA/OCSP side, look for OCSP queries around the same timestamps that Vault still granted a token. Preserve audit devices, server logs, and token accessors for any identity that authenticated with a revoked cert. Absence of a matching public IOC set means investigations should be log- and identity-centric.

• auth/cert
• auth_type=cert
• path=auth/cert/login
• tls cert auth
• ocsp
• certificate revoked
• serial number
• client_cert
• x509

What your security team should do

• Patch all Vault 1.16.0- and Vault Enterprise 1.16.1/1.15.7/1.14.11-below clusters that use TLS certificates auth, prioritizing those with OCSP configured.
• Restrict adjacent-network access to Vault API listeners to only trusted machine-identity subnets.
• Audit certs auth mounts: list mapped policies, bound subjects, and OCSP source configuration; remove unused mounts and overly broad policies.
• Rotate high-value certificates and revoke outstanding tokens issued via certs auth around the vulnerability window.
• Add detections for certs-auth successes involving subjects that the CA shows as revoked, and alert on unexpected Vault version or auth-method configuration drift.
• Track this CVE as low EPSS / non-KEV but do not deprioritize OCSP-enabled production clusters solely for that reason.