https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Wed, 07 Oct 2026 21:23:02 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-187274 EUVD-2026-187274 https://cve.radiocsirt.org/vuln/euvd-2026-187274 https://cve.radiocsirt.org/vuln/fkie_cve-2023-44273 <p>Consensys gnark-crypto through 0.11.2 allows Signature Malleability. This occurs because deserialisation of EdDSA and ECDSA signatures does not ensure that the data is in a certain interval.</p> <p>Consensys gnark-crypto through 0.11.2 allows Signature Malleability. This occurs because deserialisation of EdDSA and ECDSA signatures does not ensure that the data is in a certain interval.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2023-44273 https://cve.radiocsirt.org/vuln/ghsa-fr8m-434r-g3xp <p><strong>Affected:</strong> Go: github.com/consensys/gnark-crypto</p> <p>### Impact</p> <p>During deserialization of ECDSA and EdDSA signatures gnark-crypto did not check that the values are in the range `[1, n-1]` with `n` being the corresponding modulus (either base field modulus in case of `R` in EdDSA, and scalar field modulus in case of `s,r` in ECDSA and `s` in EdDSA). As this also allowed zero inputs, then it was possible to craft a signature which lead to null pointer dereference, leading to denial-of-service of an application. This also enabled weak signature malleability when the users assumed uniqueness of the serialized signatures (but not the underlying modulo reduced values).</p> <p>We are not aware of any users impacted by the bug. The implemented signature schemes in gnark-crypto complement the in-circuit versions in gnark, allowing to have end-to-end tests.</p> <p>### Patches</p> <p>The issue was patched in PR #449. The fix returns an error during deserialization if the values do not belong to the ranges `[1, n-1]`.</p> <p>The fix is included in release v0.12.0 and upwards.</p> <p>### Workarounds</p> <p>Users can manually validate the inputs to be in corresponding ranges when using serialized signatures (or digests of them) as unique keys.</p> <p>To address the denial-of-service, the users can install hook to recover panics and recover</p> <p>### Resources</p> <p>* [Verichains advisory](https://github.com/advisories/GHSA-9xfq-8j3r-xp5g) for signature malleability. * Fix https://github.com/Consensys/gnark-crypto/pull/449 * [Go blog post &#34;Defer, Panic, and Recover&#34;](https://go.dev/blog/def…</p> <p><strong>Affected:</strong> Go: github.com/consensys/gnark-crypto</p> <p>### Impact</p> <p>During deserialization of ECDSA and EdDSA signatures gnark-crypto did not check that the values are in the range `[1, n-1]` with `n` being the corresponding modulus (either base field modulus in case of `R` in EdDSA, and scalar field modulus in case of `s,r` in ECDSA and `s` in EdDSA). As this also allowed zero inputs, then it was possible to craft a signature which lead to null pointer dereference, leading to denial-of-service of an application. This also enabled weak signature malleability when the users assumed uniqueness of the serialized signatures (but not the underlying modulo reduced values).</p> <p>We are not aware of any users impacted by the bug. The implemented signature schemes in gnark-crypto complement the in-circuit versions in gnark, allowing to have end-to-end tests.</p> <p>### Patches</p> <p>The issue was patched in PR #449. The fix returns an error during deserialization if the values do not belong to the ranges `[1, n-1]`.</p> <p>The fix is included in release v0.12.0 and upwards.</p> <p>### Workarounds</p> <p>Users can manually validate the inputs to be in corresponding ranges when using serialized signatures (or digests of them) as unique keys.</p> <p>To address the denial-of-service, the users can install hook to recover panics and recover</p> <p>### Resources</p> <p>* [Verichains advisory](https://github.com/advisories/GHSA-9xfq-8j3r-xp5g) for signature malleability. * Fix https://github.com/Consensys/gnark-crypto/pull/449 * [Go blog post &#34;Defer, Panic, and Recover&#34;](https://go.dev/blog/def…</p> https://cve.radiocsirt.org/vuln/ghsa-fr8m-434r-g3xp https://cve.radiocsirt.org/vuln/gsd-2023-44273 gsd-2023-44273 https://cve.radiocsirt.org/vuln/gsd-2023-44273