CVE-2026-61618: SNARK Verifier: noncanonical accumulator limb decoding
SNARK Verifier is a generic (S)NARK verifier. Prior to 0.2.5, KZG accumulator public-instance limbs are decoded without consistently enforcing canonical limb bounds before elliptic-curve coordinate reconstruction. PlonkProof::read selects scalars using accumulatorindices and passes them to AccumulatorEncoding::fromrepr. For the EVM loader, LimbsEncoding::fromrepr forwards them to EvmLoader::ecpointfromlimbs in snark-verifier/src/loader/evm/loader.rs, where shl and add reconstruct coordinates before validateecpoint checks the resulting affine point rather than the original limb bounds. The related native path in snark-verifier/src/pcs/kzg/accumulator.rs can reach assertion- or unwrap-based decoding and panic instead of returning a verification error. This allows noncanonical encodings at the verifier boundary and can crash the native verifier. Standard SDK aggregation circuits are expected to constrain accumulator limbs before this boundary, which limits practical exploitability. This issue is fixed in version 0.2.5.
Event History
Frequently Asked Questions
Which deployments are most likely to be affected?
Deployments using SNARK Verifier versions prior to 0.2.5 are affected at the verifier boundary when accumulator public-instance limbs are not constrained to canonical bounds before decoding. Standard SDK aggregation circuits are expected to apply those constraints, which limits practical exploitability.
What is the impact on EVM and native verification paths?
The EVM path can reconstruct elliptic-curve coordinates from noncanonical limbs and validates the resulting affine point rather than the original limb bounds. The native KZG accumulator path can reach assertion- or unwrap-based decoding and panic instead of returning a verification error.
What should be done if upgrading is not immediately possible?
Ensure accumulator public-instance limbs are constrained to canonical bounds before they reach the verifier boundary. Using aggregation circuits that apply these limb constraints limits exposure.
How can I determine whether my deployment needs remediation?
Check whether it uses a SNARK Verifier release earlier than 0.2.5 and whether accumulator public-instance limbs can reach verification without canonical-bound constraints. Native verifier crashes during accumulator decoding may indicate the affected error-handling path.