Soundness issue with Plonky2 look up tables

published 2025-01-30 21 mo ago modified 2026-06-17 4 mo ago also GHSA-hj49-h7fq-px5h , EUVD-2025-0168

cvss: 8.6; version 3.1, CNA
cisa kev: Not listed; not in CISA's catalog
epss: 0.3%; EPSS 0.3% chance of exploitation in 30 days, percentile 26%
public exploits: 0; none known

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 -> 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.

Patch / fix

fixed in 1 links 1

crates.io plonky2 1.0.1

github.com/0xPolygonZero/plonky2@091047f commit

CISA SSVC

Exploitation: none
Automatable: yes
Technical impact: partial
Assessed: 21 mo ago (2025-01-30)

Exploit prediction

0.33% chance of exploitation in the next 30 days, higher than 26% of all scored CVEs (FIRST EPSS, 2026-11-08).

CVSS scores

assigned by	version	score	vector
CNA	3.1	8.6	CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N
GitHub	3.1	8.6	CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N

Affected packages

ecosystem	package	affected	fixed in
crates.io	plonky2	>=1.0.0, <1.0.1	1.0.1

Affected products

0xPolygonZero plonky2

Classification

Weakness

CWE-1240 Use of a Cryptographic Primitive with a Risky Implementation

References

Sources

Fencer Vulns keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.

Summary