OpenVM's OpenVmHalo2Verifier accepts non-canonical app commitments
Affects OpenVM before 1.7.0, 2.0.0-alpha before 2.0.0-rc.3, and 2.1.0-dev.0 before 2.1.0-preview, for applications relying on the Solidity verifier wrapper. Fixed in 1.7.0, 2.0.0-rc.3, and 2.1.0-preview.
- 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 1.7.0, 2.0.0-rc.3, 2.1.0-preview
- 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
OpenVM, a zero-knowledge virtual machine framework, is affected through its Solidity verifier contract (OpenVmHalo2Verifier) in versions before 1.7.0 and in 2.0 and 2.1 prerelease builds. The verifier fails to reject app commitment values that are not properly reduced modulo the BN254 field modulus, so applications using it may accept ambiguous, non-canonical commitments.
Summarized by anthropic/claude-haiku-5.5. Verify details against the original sources.
Read the original description
OpenVM is a performant and modular zkVM framework built for customization and extensibility. Before 1.7.0 in the 1.x line and in affected 2.0 and 2.1 prereleases, `OpenVmHalo2Verifier.verify` accepts `appExeCommit` and `appVmCommit` as `bytes32` values without checking that either is less than the `BN254` scalar field modulus. Although public-value and proof-data lengths are checked, callers can provide non-canonical 256-bit encodings greater than or equal to that modulus at the Solidity wrapper boundary. Applications relying on the wrapper can therefore accept non-canonical app executable and app VM commitments, creating ambiguity between the supplied byte-level values and the field elements used by the verifier. This issue is fixed in versions 1.7.0, 2.0.0-rc.3 and 2.1.0-preview.
Timeline
- CVE published
- First seen by cve.now
Affected versions
- openvm-org openvm
fixed in 1.7.0; From 2.0.0-alpha · fixed in 2.0.0-rc.3; From 2.1.0-dev.0 · fixed in 2.1.0-preview
References 9
GitHub · openvm-org/openvm
Questions about CVE-2026-62335
What does this mean?
OpenVmHalo2Verifier, the Solidity verifier wrapper, can accept app commitments written in non-canonical encodings. The bug is that it does not reject these encodings.Source: github.com
Am I affected, and how do I check?
The affected ranges are OpenVM before 1.7.0, 2.0.0-alpha up to but not including 2.0.0-rc.3, and 2.1.0-dev.0 up to but not including 2.1.0-preview. Only applications that rely on the Solidity verifier wrapper are in scope. To check, look at the openvm version your project pins and whether it uses that verifier wrapper.Source: github.com
What should I do about it?
Upgrade to 1.7.0, 2.0.0-rc.3, or 2.1.0-preview, whichever matches your release line.Source: 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