OpenVM EUVD-2026-114438

Exploitation requires an application that relies on the OpenVmHalo2Verifier Solidity verifier wrapper (versions before 1.7.0, or the affected 2.0/2.1 prereleases) and that trusts the byte-level appExeCommit/appVmCommit values at the wrapper boundary as if they were canonical field elements. The attacker-controllable input is the bytes32 commitment values passed to verify(); the specific condition is supplying a 256-bit encoding greater than or equal to the BN254 scalar field modulus (0x30644e72...f0000001). Limiting factors: impact only materializes in downstream application logic that assumes a one-to-one mapping between supplied bytes and verified field elements - deployments that already canonicalize or constrain these commitments elsewhere are not meaningfully affected, and the issue does not forge or bypass the underlying Halo2 proof check itself.

This is a moderate-severity input-validation flaw (CWE-20), not an urgent priority despite being network-reachable. The supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) reflects that the OpenVmHalo2Verifier.verify function is an on-chain, publicly callable contract method requiring no authentication or user interaction, but impact is limited to VI:L (low integrity) with VC:N and VA:N - no confidentiality or availability consequence. The real-world risk is bounded by the fact that the flaw only produces ambiguity between byte-level commitment values and field elements; it does not by itself forge a valid proof or bypass verification arithmetic. No EPSS score, KEV listing, or working exploit is present in the input - only patch/commit/PR references and vendor advisory GHSA-w82q-w67c-67wv. The vuln.today decision label is 'this_month', consistent with a genuine but non-emergency fix. One data conflict to flag: the package metadata states 'not yet patched' for rust/openvm-sdk, while the description and release references explicitly list fixed versions (1.7.0, 2.0.0-rc.3, 2.1.0-preview) - treat the fixed-version list as authoritative and verify the package feed is stale.

An actor interacting with an application built on the OpenVmHalo2Verifier Solidity wrapper submits appExeCommit and/or appVmCommit as bytes32 values greater than or equal to the BN254 scalar field modulus. Because the pre-fix wrapper only validated public-value and proof-data lengths, it forwards these non-canonical 256-bit encodings as field elements, so a downstream application may treat the raw bytes as a valid commitment that differs from the canonical field element actually used by the verifier. No public exploit identified at time of analysis; the only trigger-demonstrating artifacts are the patch's own negative-path unit tests.