snark-verifier CVE-2026-62337

Exploitation requires that the target build a recursive Halo 2 aggregation circuit using snark-verifier's Halo 2 loader with the default shim (which delegates sum_with_const to halo2-lib EccChip::sum) on an affected version (< 0.2.5), and that an attacker act as a prover able to submit a proof whose point is encoded as the identity (0, 0); such a point enters the MSM through the (Value::Constant(ONE), Value::Assigned(_)) scalar-one shortcut. Limiting factors that reduce real-world impact: per the NVD description and advisory, whether a mishandled identity element actually corrupts results or leads to acceptance of an invalid proof depends on the surrounding aggregation and final-decider checks, and the advisory does not establish universal acceptance of invalid proofs. Deployments not using this aggregation/loader path, or already on 0.2.5, are not affected.

This is a medium-severity soundness flaw in a cryptographic library, and the signals are consistent in pointing to a real-but-contained issue rather than an urgent emergency. The supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N, score 6.9) indicates a network-reachable, low-complexity, unauthenticated path with integrity-only impact (VI:L) and no confidentiality or availability impact - appropriate for a prover-controlled correctness bug in proof aggregation. There is no CISA KEV listing and no EPSS score in the input, so exploitation status is: no public exploit identified at time of analysis (the only references are the fix commits, release tag, and GHSA advisory, not PoC or exploit code). The vuln.today decision label is 'this_month', which aligns with a scheduled-remediation posture rather than act_now/emergency. One clear conflict: the input Tag labels this 'Information Disclosure', but the CVSS vector sets VC:N and VI:L - this is an integrity/soundness issue (mishandling an identity proof element could affect MSM/accumulator computation), not a confidentiality disclosure; defenders should treat it as an integrity concern. Critically, both the NVD description and the GHSA advisory explicitly state that practical exploitability depends on the surrounding aggregation and final-decider checks and that the advisory does NOT establish universal acceptance of invalid proofs - so the worst-case outcome (accepting a forged aggregated proof) is plausible but unproven. Net: a legitimate patch priority for anyone running the affected aggregation path, but not a high-real-risk widespread emergency.

A malicious prover crafts a proof containing an elliptic-curve point encoded as the identity (0, 0) and submits it to a recursive aggregation circuit that uses the Halo 2 loader in snark-verifier < 0.2.5. Because the scalar-one shortcut in EcPointLoader::multi_scalar_multiplication passes that assigned point directly into the halo2-lib EccChip::sum helper (which assumes non-identity inputs), the identity element can enter the final aggregation sum and affect the MSM or accumulator. No public exploit or PoC is identified; the advisory notes that whether this yields acceptance of an invalid proof depends on the surrounding aggregation and final-decider checks.