CVE-2025-57801 is a critical (CVSS 9.1) signature malleability flaw in gnark, the Go zero-knowledge proof framework. Before version 0.14.0, the EdDSA and ECDSA verification circuits did not assert that S is below the curve order. Upgrade to 0.14.0 and review any protocol that derives nullifiers from R and S.
What's affected
gnark versions before 0.14.0, per the record and the GitHub advisory. The fix is in 0.14.0.
The record names eddsa.go and ecdsa.go, where the Verify function used S without a range assertion.
Impact depends on your protocol. The record says that where nullifiers or anti-replay checks are derived from R and S, malleability may allow double spending.
How to check if you're exposed
gnark is a Go module, so the version is recorded in your module files.
go list -m github.com/consensys/gnark
grep -R "consensys/gnark" --include=go.mod .
go mod why -m github.com/consensys/gnark
Check every repository that builds circuits, provers or verifier contracts, not only the main service. Then look at how your protocol uses signatures inside circuits. If a signature value is used to derive an identifier that must be unique, your design is in the group the record warns about.
What to do now
- Find every Go module that depends on gnark and note the version.
- Upgrade to gnark 0.14.0 or later and recompile your circuits.
- Redeploy any verifier or proving key material that must be regenerated after a circuit change. Check the gnark release notes for what that means for your setup.
- Review whether any nullifier, replay check or unique identifier is derived from R and S, and move to a value that does not depend on the malleable parts of the signature.
Why it matters
A signature is malleable when more than one encoding of the same signature verifies. Here the circuit used S without asserting that it lies between zero and the group order, so several different witnesses satisfied the same public inputs. For a signature check alone that may sound harmless. For a protocol that treats the signature as a unique token, it is not.
This is a good example of why cryptographic code needs its own review path. The flaw is not a crash or a memory error. It is a missing constraint, and only someone reading the circuit with the protocol in mind would notice it.
The record classifies the weakness as CWE-347 (Improper Verification of Cryptographic Signature).
Fixes in a proving framework can change circuits, and a changed circuit can mean new keys. Do not assume a library bump is the whole job. Read the project's release notes, rebuild in a staging environment, and confirm the new circuit verifies the way your protocol expects before it reaches production.
The record shows this CVE is not in the CISA Known Exploited Vulnerabilities catalog.
Quick check
Does upgrading gnark alone fix my protocol?
It removes the library flaw. If your design derives replay protection from R and S, review that design too, because the advisory says that is where malleability can be abused.
Which version fixes CVE-2025-57801?
gnark 0.14.0.
Sources
Last reviewed: 18 October 2026.
