Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
8 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Go github.com/consensys/gnark >= 0.12.0, <= 0.12.0
Fixed in
0.13.0· Vendor fix available
Issue
Impact For optimizing the scalar multiplication algorithm in circuit for some curves, gnark uses fake-GLV algorithm in case the curve doesn't support true-GLV. For this to work, we need to compute the scalar decomposition using the Half GCD method in gnark-crypto. However, for some of the inputs the algorithm didn't converge quickly enough. In case the prover accepts untrusted witness, it could lead to denial of service as the prover gets stuck in a very slowly converging loop. Thanks to @feltroidprime for reporting the issue and proposing a fix. Patches The issue has been patched in gnark-crypto commit https://github.com/Consensys/gnark-crypto/commit/56600883e0e9f9b159e9c7000b94e76185ec3d0d. The dependency update is implemented in gnark commit https://github.com/Consensys/gnark/commit/68be6cede36e387ab760725beabd3c96cc94e6dc. Workarounds This update doesn't require recompiling the circuits as the issue is in the hint function. The users can update the gnark-crypto dependency to the…
Recommended action: Upgrade to 0.13.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In version before, sig.s used without asserting 0 ≤ S < order in Verify function in eddsa.go and ecdsa.go, which will lead to signature malleability vulnerability. Impact Since 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, S), this enables signature malleability and may lead to double spending. Exploitation Result Credits XlabAI Team of Tencent Xuanwu Lab Atuin Automated Vulnerability Discovery Engine SJTU Group of Software Security In Progress Prof. Yu Yu's Lab at SJTU Additional mitigation The initial patch added check for s <= curve order, omitting the case s == curve order. Even though the case is unlikely to be exploitable (requires finding a preimage for H(R || A || M)), then it is additionally fixed in https://github.com/Consensys/gnark/pull/1684 (commit…
Recommended action: Upgrade to 0.14.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Thanks @pventuzelo for reporting. From the correspondence: Hi, We (Fuzzinglabs & Lambdaclass) found that during deserialization of certain files representing a VerifyingKey, an excessive memory allocation is happening consuming a lot of resources and even triggering a crash with the error fatal error: runtime: out of memory. Please find the details below: Vulnerability Details - Severity: Critical - DoS - Affected Component: Deserialization Environment - Compiler Version: go version go1.22.2 linux/amd64 - Distro Version: Ubuntu 24.04.1 LTS - Additional Environment Details: - github.com/consensys/gnark v0.11.0 - github.com/consensys/gnark-crypto v0.14.1-0.20240909142611-e6b99e74cec1 Steps to Reproduce You can download the needed files here: https://drive.google.com/drive/folders/1KQ5I3vv4bUllvqbatGappwbAkIcR2NI?usp=sharing You have to run in a terminal. Running the provided code will result in a memory crash or an extremely large memory allocation, which can be observed using…
Recommended action: Upgrade to 0.11.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The summary is that the proof of knowledge associated to a commitment is crucial to bind the commitment to the actual circuit variables that were supposed to be committed. However, the same σ is used for all proofs of knowledge for the commitments, which allows mixing between them, making it possible to fix the value of all but one commitment before choosing the circuit variable assignments. In more detail: To simplify notation, let us consider the case of two commitments, each to only a single variable. Let's say the basis elements for those commitments are K0 and K1. Then the proving key will contain K0 and K1, and also σK0 and σK1 for the proof of knowledge. The honest prover assigning a to the first circuit variable and b to the second will then produce commitments D0 = aK0 D1 = bK1 Out of the two D's, a challenge r for the commitment folding will be generated. The folded commitment will then be Dfolded = D0 + rD1 = aK0 + rbK1 The honest prover will supply a fitting…
Recommended action: Upgrade to 0.11.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
This report concerns the Groth16 prover when used with commitments (as in frontend.Committer). To simplify exposition of the issue, I will focus on the case of a single commitment, to only private witnesses. But the issue should be present whenever commitments are used that include private witnesses. The commitment to private witnesses wi is computed as where bi would be ProvingKey.CommitmentKeys[0].Basis[i] in the code. While this is a binding commitment, it is not hiding. In practice, an adversary will know the points bi, as they are part of the proving key, and can verify correctness of a guess for the values of wi by computing c' as the right hand side of the above formula, and checking whether c' is equal to c. I attach a proof of concept that demonstrates this. This breaks the perfect zero-knowledge property of Groth16, so the Groth16 scheme using commitments to private witnesses as implemented by gnark fails to be a zk-SNARK. The code indicates that the extension to Groth16…
Recommended action: Upgrade to 0.11.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact gnark provides a gadget in the standard library to allow optimized checking of the bitwidth of the inputs. The gadget works by constructing a fixed lookup table containing all valid entries, partitioning the input and checking that all parts are inside the lookup table. The range checker gadget did not take into account that the highest partition may be less than the width limit, allowing the inputs to be up to 16 bits wider than checked. Range checking gadget is extensively used in field emulation. Users using any dependant gadget (ECDSA verification, proof recursion etc.) is impacted. We consider the impact of the vulnerability being low as the number of attacker-modifiable bits is significantly smaller compared to the bit-width of scalar field modulus and it won't be possible to construct inputs which would allow to overflow the scalar field. Patches The issue has been patched in the stable branch of gnark. Due to low severity of the issue no emergency release will be…
Recommended action: Upgrade to 0.9.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The vulnerability allows a third party to derive a valid proof from a valid initial tuple {proof, publicinputs}, corresponding to the same public inputs as the initial proof. It is due to a randomness being generated using a small part of the scratch memory describing the state, allowing for degrees of freedom in the transcript. Note that the impact is limited to the PlonK verifier smart contract. Patches We still use a hash function on some data to have a pseudo rng, but instead of hashing the first 32 bytes of the state ( let random := mod(keccak256(state, 0x20), rmod) ) we hash the whole state at this point of the verifier as if it was a Fiat Shamir transcript: Workarounds In the function batchverifymultipoints, the variable random (corresponding to u in the paper, step 12 of the plonk verification process) should depend on statefoldeddigestsx, statefoldeddigestsy, proofgrandproductcommitmentx, proofgrandproductcommitmenty and statezeta (by hashing those values for instance).
Recommended action: Upgrade to 0.9.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact For some in-circuit values, it is possible to construct two valid decomposition to bits. In addition to the canonical decomposition of a, for small values there exists a second decomposition for a+r (where r is the modulus the values are being reduced by). The second decomposition was possible due to overflowing the field where the values are defined. Internally, the comparison methods frontend.API.Cmp and frontend.API.IsLess used binary decomposition and checked the bitwise differences. This allows a malicious prover to construct a valid proof for a statement a < b even if a b. The issue impacts all users using API.Cmp or API.IsLess methods. Additionally, it impacts the users using bits.ToBinary or API.ToBinary methods if full-width decomposition is requested (the default behaviour if no options are given). The issues does not impact comparison methods in field emulation (package std/math/emulated) and dedicated comparison package (std/math/cmp). Patches Fix has been…
Recommended action: Upgrade to 0.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.