CVE-2025-64186: evervault-go · Improper Verification of Cryptographic Signature
Affects evervault-goSource CVE Database V5
Not known to be exploited · CVSS 8.7 High : upgrade to 1.3.2 soon.
Data as of 26 Oct 2026, 17:16 UTC
- EPSS
- 0.1% chance of exploitation in 30 days – higher than 3% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available – fixed in 1.3.2
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:NExploitation evidence
Disclosed: evidence found.
CVE published 12 Nov 2025
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.
What to do
Upgrade evervault/evervault-go to 1.3.2.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
GitHubevervault/evervault-gopkg:github/evervault/evervault-goOther threats | Affected
| Fixed in
|
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
AI-suggested
European organizations should immediately upgrade all instances of evervault-go SDK to version 1.3.2 or later to benefit from the official fix. For environments where upgrading is not feasible, especially those hosting enclaves outside Evervault infrastructure, implement strict application-level validation to reject attestation documents missing PCR8 or any required PCR values. Modify attestation verification logic to enforce explicit presence and non-emptiness of PCR8 and consider adding custom pre-validation layers to ensure completeness of attestation data before caching or trusting it. Additionally, restrict network access and domain name permissions to prevent unauthorized entities from serving requests from evervault domain names, thereby reducing the attack surface. Conduct thorough audits of enclave attestation processes and logs to detect anomalies or incomplete attestations. Incorporate continuous monitoring for updates from Evervault and related security advisories. Finally, integrate these mitigations into secure software development lifecycle (SDLC) practices and incident response plans to ensure rapid response to any exploitation attempts.
Description
Evervault is a payment security solution. A vulnerability was identified in the `evervault-go` SDK’s attestation verification logic in versions of `evervault-go` prior to 1.3.2 that may allow incomplete documents to pass validation. This may cause the client to trust an enclave operator that does not meet expected integrity guarantees. The exploitability of this issue is limited in Evervault-hosted environments as an attacker would require the pre-requisite ability to serve requests from specific evervault domain names, following from our ACME challenge based TLS certificate acquisition pipeline. The vulnerability primarily affects applications which only check PCR8. Though the efficacy is also reduced for applications that check all PCR values, the impact is largely remediated by checking PCR 0, 1 and 2. The identified issue has been addressed in version 1.3.2 by validating attestation documents before storing in the cache, and replacing the naive equality checks with a new SatisfiedBy check. Those who useevervault-go to attest Enclaves that are hosted outside of Evervault environments and cannot upgrade have two possible workarounds available. Modify the application logic to fail verification if PCR8 is not explicitly present and non-empty and/or add custom pre-validation to reject documents that omit any required PCRs.