CVE-2025-57801: CWE-347: Improper Verification of Cryptographic Signature in Consensys gnark
gnark is a zero-knowledge proof system framework. In versions prior to 0.14.0, the Verify function in eddsa.go and ecdsa.go used the S value from a signature without asserting that 0 ≤ S < order, leading to a signature malleability vulnerability. Because gnark’s native EdDSA and ECDSA circuits lack essential constraints, multiple distinct witnesses can satisfy the same public inputs. In protocols where nullifiers or anti-replay checks are derived from R and S, this enables signature malleability and may allow double spending. This issue has been addressed in version 0.14.0.
AI Analysis
Technical Summary
CVE-2025-57801 is a high-severity cryptographic signature verification vulnerability affecting versions of Consensys' gnark framework prior to 0.14.0. Gnark is a zero-knowledge proof system framework that supports native EdDSA and ECDSA signature circuits. The vulnerability arises from improper verification of the S value in cryptographic signatures within the Verify function in eddsa.go and ecdsa.go. Specifically, the code fails to assert that the signature component S satisfies the condition 0 ≤ S < order, which is a fundamental requirement to prevent signature malleability. Signature malleability allows multiple distinct signatures to be considered valid for the same message, undermining the uniqueness and integrity of signatures. In gnark's context, this is exacerbated because its native EdDSA and ECDSA circuits lack essential constraints, allowing multiple distinct witnesses to satisfy the same public inputs. This flaw can be exploited in protocols that derive nullifiers or anti-replay checks from the signature components R and S, enabling attackers to manipulate signatures to bypass replay protections or double spend tokens. The vulnerability does not require authentication or user interaction to exploit but requires local access (AV:L) to the vulnerable system. The CVSS 4.0 score is 8.6 (high), reflecting the high impact on confidentiality and integrity, with limited availability impact. The issue was addressed in gnark version 0.14.0 by adding proper constraints and verification checks on the S value to prevent malleability. No known exploits are currently reported in the wild.
Potential Impact
For European organizations leveraging gnark for zero-knowledge proof implementations—particularly in blockchain, privacy-preserving protocols, or cryptographic applications—this vulnerability poses a significant risk. Exploitation could allow attackers to forge or manipulate signatures, leading to double spending or replay attacks in financial or identity systems. This undermines trust in cryptographic guarantees, potentially causing financial losses, regulatory non-compliance (especially under GDPR if data integrity is compromised), and reputational damage. Given the growing adoption of zero-knowledge proofs in privacy-sensitive sectors such as finance, healthcare, and government services in Europe, the impact could be widespread. The vulnerability could also affect interoperability and security of cross-border transactions and services relying on gnark-based proofs. Although no exploits are known yet, the high severity and ease of exploitation without authentication suggest that threat actors could develop attacks rapidly once the vulnerability is public knowledge.
Mitigation Recommendations
European organizations using gnark should immediately upgrade to version 0.14.0 or later, where the vulnerability is fixed. Beyond upgrading, organizations should audit their use of gnark’s EdDSA and ECDSA circuits to ensure that signature verification is correctly implemented and that no custom modifications reintroduce malleability risks. It is advisable to implement additional application-layer checks for signature uniqueness and replay protection, such as maintaining nonce or nullifier state independently of signature components. Security teams should conduct thorough code reviews and penetration testing focusing on signature handling and zero-knowledge proof validation. Monitoring for anomalous transaction patterns indicative of double spending or replay attacks should be enhanced. For critical systems, consider isolating gnark-based components and applying strict access controls to limit local exploitation opportunities. Finally, maintain awareness of updates from Consensys and the gnark project for any further patches or advisories.
Affected Countries
Germany, France, United Kingdom, Netherlands, Switzerland, Luxembourg, Sweden
CVE-2025-57801: CWE-347: Improper Verification of Cryptographic Signature in Consensys gnark
Description
gnark is a zero-knowledge proof system framework. In versions prior to 0.14.0, the Verify function in eddsa.go and ecdsa.go used the S value from a signature without asserting that 0 ≤ S < order, leading to a signature malleability vulnerability. Because gnark’s native EdDSA and ECDSA circuits lack essential constraints, multiple distinct witnesses can satisfy the same public inputs. In protocols where nullifiers or anti-replay checks are derived from R and S, this enables signature malleability and may allow double spending. This issue has been addressed in version 0.14.0.
AI-Powered Analysis
Technical Analysis
CVE-2025-57801 is a high-severity cryptographic signature verification vulnerability affecting versions of Consensys' gnark framework prior to 0.14.0. Gnark is a zero-knowledge proof system framework that supports native EdDSA and ECDSA signature circuits. The vulnerability arises from improper verification of the S value in cryptographic signatures within the Verify function in eddsa.go and ecdsa.go. Specifically, the code fails to assert that the signature component S satisfies the condition 0 ≤ S < order, which is a fundamental requirement to prevent signature malleability. Signature malleability allows multiple distinct signatures to be considered valid for the same message, undermining the uniqueness and integrity of signatures. In gnark's context, this is exacerbated because its native EdDSA and ECDSA circuits lack essential constraints, allowing multiple distinct witnesses to satisfy the same public inputs. This flaw can be exploited in protocols that derive nullifiers or anti-replay checks from the signature components R and S, enabling attackers to manipulate signatures to bypass replay protections or double spend tokens. The vulnerability does not require authentication or user interaction to exploit but requires local access (AV:L) to the vulnerable system. The CVSS 4.0 score is 8.6 (high), reflecting the high impact on confidentiality and integrity, with limited availability impact. The issue was addressed in gnark version 0.14.0 by adding proper constraints and verification checks on the S value to prevent malleability. No known exploits are currently reported in the wild.
Potential Impact
For European organizations leveraging gnark for zero-knowledge proof implementations—particularly in blockchain, privacy-preserving protocols, or cryptographic applications—this vulnerability poses a significant risk. Exploitation could allow attackers to forge or manipulate signatures, leading to double spending or replay attacks in financial or identity systems. This undermines trust in cryptographic guarantees, potentially causing financial losses, regulatory non-compliance (especially under GDPR if data integrity is compromised), and reputational damage. Given the growing adoption of zero-knowledge proofs in privacy-sensitive sectors such as finance, healthcare, and government services in Europe, the impact could be widespread. The vulnerability could also affect interoperability and security of cross-border transactions and services relying on gnark-based proofs. Although no exploits are known yet, the high severity and ease of exploitation without authentication suggest that threat actors could develop attacks rapidly once the vulnerability is public knowledge.
Mitigation Recommendations
European organizations using gnark should immediately upgrade to version 0.14.0 or later, where the vulnerability is fixed. Beyond upgrading, organizations should audit their use of gnark’s EdDSA and ECDSA circuits to ensure that signature verification is correctly implemented and that no custom modifications reintroduce malleability risks. It is advisable to implement additional application-layer checks for signature uniqueness and replay protection, such as maintaining nonce or nullifier state independently of signature components. Security teams should conduct thorough code reviews and penetration testing focusing on signature handling and zero-knowledge proof validation. Monitoring for anomalous transaction patterns indicative of double spending or replay attacks should be enhanced. For critical systems, consider isolating gnark-based components and applying strict access controls to limit local exploitation opportunities. Finally, maintain awareness of updates from Consensys and the gnark project for any further patches or advisories.
Affected Countries
For access to advanced analysis and higher rate limits, contact root@offseq.com
Technical Details
- Data Version
- 5.1
- Assigner Short Name
- GitHub_M
- Date Reserved
- 2025-08-20T14:30:35.009Z
- Cvss Version
- 4.0
- State
- PUBLISHED
Threat ID: 68a8cce7ad5a09ad0022289e
Added to database: 8/22/2025, 8:02:47 PM
Last enriched: 8/22/2025, 8:17:58 PM
Last updated: 8/22/2025, 8:17:58 PM
Views: 2
Related Threats
CVE-2025-9356: Stack-based Buffer Overflow in Linksys RE6250
HighCVE-2025-9355: Stack-based Buffer Overflow in Linksys RE6250
HighCVE-2025-43761: CWE-79 Improper Neutralization of Input During Web Page Generation (XSS or 'Cross-site Scripting') in Liferay Portal
MediumCVE-2025-24902: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') in LabRedesCefetRJ WeGIA
CriticalCVE-2025-52451: CWE-20 Improper Input Validation in Salesforce Tableau Server
HighActions
Updates to AI analysis are available only with a Pro account. Contact root@offseq.com for access.
Need enhanced features?
Contact root@offseq.com for Pro access with improved analysis and higher rate limits.