OpenVM's OpenVmHalo2Verifier accepts non-canonical app commitments

openvm · Improper input validation · CWE-20

Affectedopenvm

FixNo fix listed yet.

PublishedOct 30, 20:03 · GitHub_M

ScoredOct 30 · 6.9 · GitHub_M

Exploit code publicNone known · checked 21:18 UTC

ExploitedNone known · CISA KEV checked 22:07 UTC

What we know

No known exploitation. CISA KEV, checked 22:07 UTC.

No public exploit code known. Exploit-DB, Metasploit, Nuclei, checked 21:18 UTC.

An attacker only needs network access to the target. No login needed. CVSS: network, no privileges.

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.

From GitHub_M

Affected and fixed versions

ProductAffectedFixed inopenvm< 1.7.0–openvm>= 2.0.0-alpha, < 2.0.0-rc.3–openvm>= 2.1.0-dev.0, < 2.1.0-preview–

Exploit code

Exploit-DBnone knownMetasploitnone knownNucleinone known

References

Other CVEs in openvm

All 4 →

8.7OpenVM: MemoryMerkleAir allows below-leaf rows to alter memory roots · CVE-2026-62333Oct 30 8.7OpenVM's OpenVmHalo2Verifier self-call can bypass proof verification · CVE-2026-62334Oct 30 8.7`openvm-pairing` pairing check missing proper subfield check on scaling factor · CVE-2026-46669Jun 10