snark-verifier CVE-2026-61618

Exploitation requires the ability to supply accumulator public-instance values (the scalars selected by accumulator_indices and passed to AccumulatorEncoding::from_repr) to a KZG-based SNARK verifier built from snark-verifier prior to 0.2.5. The concrete prerequisite is a deployment where accumulator limbs are NOT already constrained in-circuit before the verifier boundary: the vendor states that standard SDK aggregation circuits constrain these limbs beforehand, which is the primary limiting factor on real-world exploitability. The crash/DoS specifically affects the native verifier path (snark-verifier/src/pcs/kzg/accumulator.rs) via assertion/unwrap-based decoding; the EVM loader path (ec_point_from_limbs) instead accepted non-canonical encodings because validate_ec_point checked the reconstructed affine point rather than the original limb bounds. No authentication or user interaction is indicated by the vector (PR:N/UI:N).

This is a moderate, defense-in-depth hardening fix rather than a high-urgency emergency. The supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) scores 6.9 and indicates a vulnerable system impact only to integrity (VI:L), with no confidentiality or availability metric set, yet the tags and the advisory itself describe a denial-of-service crash on the native verifier path - so the input signals are internally inconsistent about whether the primary impact is integrity (accepting non-canonical encodings) or availability (a panic/crash). No EPSS score, no CISA KEV listing, and no working PoC are present in the input; the only references are the fix commit, the v0.2.5 release, and the GHSA advisory. The vuln.today decision label is 'this_month' (not act_now/emergency), which is consistent with the vendor's own statement that standard SDK aggregation circuits constrain accumulator limbs before the verifier boundary, materially limiting practical exploitability. Net: treat as a scheduled-patch item, not a drop-everything priority - the network/unauthenticated reachability is real, but the real-world impact is bounded to deployments that feed unconstrained accumulator public inputs into the native verifier.

An attacker who can supply the public-instance values to a KZG-based SNARK verifier crafts accumulator limbs that exceed the configured canonical limb bound. On the native verifier path these malformed limbs reach assertion/unwrap-based decoding and panic, crashing the verifier instead of returning a clean verification error; on the EVM path non-canonical encodings pass limb checking before point validation. No public exploit code is identified in the input, and exploitation requires a deployment that does not already constrain accumulator limbs in-circuit before this boundary.