https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 06 Oct 2026 16:27:54 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-212853 EUVD-2026-212853 https://cve.radiocsirt.org/vuln/euvd-2026-212853 https://cve.radiocsirt.org/vuln/fkie_cve-2025-24802 <p>Plonky2 is a SNARK implementation based on techniques from PLONK and FRI. Lookup tables, whose length is not divisible by 26 = floor(num_routed_wires / 3) always include the 0 -&gt; 0 input-output pair. Thus a malicious prover can always prove that f(0) = 0 for any lookup table f (unless its length happens to be divisible by 26). The cause of problem is that the LookupTableGate-s are padded with zeros. A workaround from the user side is to extend the table (by repeating some entries) so that its length becomes divisible by 26. This vulnerability is fixed in 1.0.1.</p> <p>Plonky2 is a SNARK implementation based on techniques from PLONK and FRI. Lookup tables, whose length is not divisible by 26 = floor(num_routed_wires / 3) always include the 0 -&gt; 0 input-output pair. Thus a malicious prover can always prove that f(0) = 0 for any lookup table f (unless its length happens to be divisible by 26). The cause of problem is that the LookupTableGate-s are padded with zeros. A workaround from the user side is to extend the table (by repeating some entries) so that its length becomes divisible by 26. This vulnerability is fixed in 1.0.1.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2025-24802 https://cve.radiocsirt.org/vuln/ghsa-hj49-h7fq-px5h <p><strong>Affected:</strong> crates.io: plonky2</p> <p>### Impact Lookup tables, whose length is not divisible by `26 = floor(num_routed_wires / 3)` always include the `0 -&gt; 0` input-output pair. Thus a malicious prover can always prove that `f(0) = 0` for any lookup table f (unless its length happens to be divisible by 26).</p> <p>The cause of problem is that the `LookupTableGate`-s are [padded with zeros](https://github.com/0xPolygonZero/plonky2/blob/main/plonky2/src/plonk/prover.rs#L97).</p> <p>The fix is done by padding with an existing table pair, similarly to `LookupGate`.</p> <p>A workaround from the user side is to extend the table (by repeating some entries) so that its length becomes divisible by 26.</p> <p>Fortunately, the seemingly most common use case, namely, hash functions with table-based sbox-es, are not vulnerable:</p> <p>* both Monolith&#39;s and Tip5/Tip4&#39;s s-box tables already map 0 to 0; * more generally, forcing several (0,0) pairs inside such a hash function appears to be a too strong restriction to find an otherwise valid trace.</p> <p>A malicious prover exploiting this could cheat a circuit which statement is the following: - output `x + f(x)` for some private input `x`, where `f(x) := 100 - x` is implemented by a lookup table.</p> <p>A malicious prover would be able to convince an honest verifier that they know an `0 &lt;= x &lt; 64` such that `x + (100 - x) = 0`.</p> <p>### Patches Yes, upgrade to v1.0.1</p> <p>### Workarounds No</p> <p>### References</p> <p><strong>Affected:</strong> crates.io: plonky2</p> <p>### Impact Lookup tables, whose length is not divisible by `26 = floor(num_routed_wires / 3)` always include the `0 -&gt; 0` input-output pair. Thus a malicious prover can always prove that `f(0) = 0` for any lookup table f (unless its length happens to be divisible by 26).</p> <p>The cause of problem is that the `LookupTableGate`-s are [padded with zeros](https://github.com/0xPolygonZero/plonky2/blob/main/plonky2/src/plonk/prover.rs#L97).</p> <p>The fix is done by padding with an existing table pair, similarly to `LookupGate`.</p> <p>A workaround from the user side is to extend the table (by repeating some entries) so that its length becomes divisible by 26.</p> <p>Fortunately, the seemingly most common use case, namely, hash functions with table-based sbox-es, are not vulnerable:</p> <p>* both Monolith&#39;s and Tip5/Tip4&#39;s s-box tables already map 0 to 0; * more generally, forcing several (0,0) pairs inside such a hash function appears to be a too strong restriction to find an otherwise valid trace.</p> <p>A malicious prover exploiting this could cheat a circuit which statement is the following: - output `x + f(x)` for some private input `x`, where `f(x) := 100 - x` is implemented by a lookup table.</p> <p>A malicious prover would be able to convince an honest verifier that they know an `0 &lt;= x &lt; 64` such that `x + (100 - x) = 0`.</p> <p>### Patches Yes, upgrade to v1.0.1</p> <p>### Workarounds No</p> <p>### References</p> https://cve.radiocsirt.org/vuln/ghsa-hj49-h7fq-px5h