gnark
Products
1- 2 CVEs
Recent CVEs
2| CVE | Vendor / Product | Sev | Risk | CVSS | EPSS | KEV | Published | Description |
|---|---|---|---|---|---|---|---|---|
| CVE-2025-58157 | 0.00 | — | 0.00 | Aug 29, 2025 | gnark is a zero-knowledge proof system framework. In version 0.12.0, there is a potential denial of service vulnerability when computing scalar multiplication is using the fake-GLV algorithm. This is because the algorithm didn't converge quickly enough for some of the inputs. This issue has been patched in version 0.13.0. | |||
| CVE-2025-57801 | 0.00 | — | 0.00 | Aug 22, 2025 | 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. |
- CVE-2025-58157Aug 29, 2025risk 0.00cvss —epss 0.00
gnark is a zero-knowledge proof system framework. In version 0.12.0, there is a potential denial of service vulnerability when computing scalar multiplication is using the fake-GLV algorithm. This is because the algorithm didn't converge quickly enough for some of the inputs. This issue has been patched in version 0.13.0.
- CVE-2025-57801Aug 22, 2025risk 0.00cvss —epss 0.00
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.