CVE-2025-57801 Overview
CVE-2025-57801 is a signature malleability vulnerability affecting Consensys gnark, a zero-knowledge proof system framework written in Go. The vulnerability exists in the Verify function within eddsa.go and ecdsa.go files, where the S value from a signature was used without properly asserting that 0 ≤ S < order. This missing constraint allows multiple distinct witnesses to satisfy the same public inputs, creating a dangerous signature malleability condition.
Critical Impact
In protocols where nullifiers or anti-replay checks are derived from R and S values, this vulnerability enables signature malleability attacks and may allow double spending in blockchain and cryptographic applications.
Affected Products
- Consensys gnark versions prior to 0.14.0
- Applications using gnark's native EdDSA circuits
- Applications using gnark's native ECDSA circuits
Discovery Timeline
- 2025-08-22 - CVE CVE-2025-57801 published to NVD
- 2025-09-12 - Last updated in NVD database
Technical Details for CVE-2025-57801
Vulnerability Analysis
The vulnerability stems from improper verification of cryptographic signatures (CWE-347) in gnark's EdDSA and ECDSA circuit implementations. Zero-knowledge proof systems rely on mathematical constraints to ensure that proofs are valid and cannot be manipulated. In the affected versions, the signature verification circuits failed to enforce that the scalar value S is within the valid range of the elliptic curve's order.
When signature components R and S are not properly bounded, an attacker can create alternative valid signatures for the same message by manipulating the S value. This is particularly dangerous in zero-knowledge proof contexts where the signature values may be used as inputs to nullifier generation or replay protection mechanisms.
Root Cause
The root cause is the absence of range assertions on signature scalar values in the circuit constraints. According to RFC 8032 Section 3.4, EdDSA implementations must verify that S is less than the group order. The gnark implementation was missing the equivalent constraint in its zero-knowledge circuit representation, allowing values of S that exceed the curve's order to pass verification.
Attack Vector
This vulnerability requires local access to exploit. An attacker with knowledge of a valid signature can mathematically derive alternative signature values that satisfy the same verification equation. In blockchain applications using gnark for zero-knowledge proofs, this could allow:
- Submitting multiple transactions that appear unique but derive from the same underlying signature
- Bypassing nullifier-based double-spend protections
- Replaying transactions in systems that use R and S for anti-replay derivation
The security patch adds the necessary scalar boundary assertions:
// Security patch in std/signature/ecdsa/ecdsa.go
if err != nil {
panic(err)
}
scalarApi.AssertIsLessOrEqual(&sig.S, scalarApi.Modulus())
scalarApi.AssertIsLessOrEqual(&sig.R, scalarApi.Modulus())
pkpt := sw_emulated.AffinePoint[T](pk)
msInv := scalarApi.Div(msg, &sig.S)
rsInv := scalarApi.Div(&sig.R, &sig.S)
Source: GitHub Commit Update
// Security patch in std/signature/eddsa/eddsa.go
Y: curve.Params().Base[1],
}
// Assert S < GroupSize (see https://datatracker.ietf.org/doc/html/rfc8032#section-3.4)
curve.API().AssertIsLessOrEqual(sig.S, curve.Params().Order)
//[S]G-[H(R,A,M)]*A
_A := curve.Neg(pubKey.A)
Q := curve.DoubleBaseScalarMul(base, _A, sig.S, hRAM)
Source: GitHub Commit Update
Detection Methods for CVE-2025-57801
Indicators of Compromise
- Multiple zero-knowledge proofs submitted with mathematically related signature values
- Nullifier collisions or duplicate nullifier attempts in protocols using gnark circuits
- Unexpected transaction replay attempts in blockchain applications
- Anomalous signature verification patterns where S values exceed expected ranges
Detection Strategies
- Implement off-chain validation to verify signature scalar values are within proper bounds before accepting proofs
- Monitor for duplicate or near-duplicate transaction submissions that may indicate malleability exploitation
- Audit existing gnark circuit implementations for missing scalar range assertions
- Review transaction logs for patterns consistent with double-spend attempts
Monitoring Recommendations
- Enable detailed logging for signature verification operations in applications using gnark
- Implement alerting for nullifier collision attempts or duplicate proof submissions
- Monitor dependency versions in Go modules to identify systems running vulnerable gnark versions
- Track blockchain mempool activity for suspicious signature patterns in ZK-proof based systems
How to Mitigate CVE-2025-57801
Immediate Actions Required
- Upgrade gnark to version 0.14.0 or later immediately
- Audit all deployed circuits using gnark's EdDSA or ECDSA implementations
- Review transaction history for potential exploitation in production systems
- Regenerate proofs for any circuits that were compiled with vulnerable versions
Patch Information
The vulnerability has been addressed in gnark version 0.14.0. The fix adds proper scalar boundary assertions using AssertIsLessOrEqual to ensure that signature components R and S are within the valid modulus range. Organizations should update their Go module dependencies to pull the patched version.
For detailed information, refer to the GitHub Security Advisory GHSA-95v9-hv42-pwrj and the security patch commit.
Workarounds
- If immediate upgrade is not possible, implement additional off-chain signature validation that checks S < order before proof verification
- Add application-layer nullifier tracking independent of signature-derived values
- Consider implementing custom circuit constraints that manually enforce scalar bounds until upgrade is complete
- Temporarily pause acceptance of new proofs in high-value applications until the patch can be deployed
# Update gnark dependency to patched version
go get github.com/consensys/gnark@v0.14.0
go mod tidy
# Verify the installed version
go list -m github.com/consensys/gnark
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

