SNARK Verifier: noncanonical accumulator limb decoding
Affects snark-verifier versions before 0.2.5, in both the generated EVM verifier path and the native verifier path. The fix is in 0.2.5, and no vendor severity rating is given.
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Unclear
- Fix
- Fixed in 0.2.5
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
SNARK Verifier, a generic zero-knowledge proof verifier library, is affected because it does not consistently enforce canonical bounds on KZG accumulator limbs during decoding. The impact is that malformed, noncanonical proof encodings can be accepted at the EVM and native verifier boundaries, and the native verifier can crash (panic) instead of returning a clean verification error.
Summarized by anthropic/claude-haiku-5.5. Verify details against the original sources.
Read the original description
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 `accumulator_indices` and passes them to `AccumulatorEncoding::from_repr`. For the EVM loader, `LimbsEncoding::from_repr` forwards them to `EvmLoader::ec_point_from_limbs` in `snark-verifier/src/loader/evm/loader.rs`, where `shl` and `add` reconstruct coordinates before `validate_ec_point` 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.
Timeline
- CVE published
- First seen by cve.now
Affected versions
- axiom-crypto snark-verifier
fixed in 0.2.5
References 3
GitHub · axiom-crypto/snark-verifier
Questions about CVE-2026-61618
What does this mean?
The verifier accepts non-canonical encodings of accumulator limbs at its boundary. In the native verifier, malformed accumulator public inputs can cause a panic instead of a verification error, which is a denial of service. In the generated EVM verifier, accumulator coordinates are rebuilt from public-instance limbs before point validation.Source: github.com, github.com
Am I affected, and how do I check?
Versions of snark-verifier before 0.2.5 are affected, and the advisory specifically mentions v0.2.4 and earlier. To check, look at the snark-verifier version pinned in your Cargo.toml or Cargo.lock. The bug is in the generated EVM verifier path and the native verifier path.Source: github.com, github.com
What should I do about it?
Upgrade snark-verifier to 0.2.5, which is the listed fixed version. The facts do not list a workaround.Source: github.com, github.com
Is it being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data