OpenVM's Halo2 verifier accepts non-canonical app commitments
Key facts
- Attack vector
- Network
- Privileges required
- None
- User interaction
- None
- Attack complexity
- Low
- Attack requirements
- None
- Impact type
- —
- Confidentiality · integrity · availability
- None · Low · None
- Fix status
- Fixed
Attack profile from CVSS 4.0 · CNA. Fix status from CNA.
Summary
OpenVM, a zkVM framework, is affected before 1.7.0, from 2.0.0-alpha before 2.0.0-rc.3, and from 2.1.0-dev.0 before 2.1.0-preview. The OpenVmHalo2Verifier.verify function does not check that appExeCommit and appVmCommit are less than the BN254 scalar field modulus (CWE-20). An unauthenticated attacker can supply non-canonical 256-bit encodings, so applications relying on the Solidity wrapper accept commitments that are ambiguous with the field elements the verifier uses.
Written with Claude Haiku 5.5 from the sources below · 2026-10-30
Description from the CNA
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.
Why it matters now
SSVC decision points
CISA ADP · SSVC 2.0.3
- Exploitation
- None
- Automatable
- Yes
- Technical impact
- Partial
The decision (Track, Attend, Act) also depends on your mission and well-being impact; see CISA's SSVC guide.
Affected products
| Vendor | Product | Affected versions | Fixed in | Status | Source |
|---|---|---|---|---|---|
| openvm-org | openvm | before 1.7.0; 2.0.0-alpha to before 2.0.0-rc.3; 2.1.0-dev.0 to before 2.1.0-preview | 1.7.0, 2.0.0-rc.3, 2.1.0-preview | Patch available | CNA |
- openvm Vendoropenvm-org Affected before 1.7.0; 2.0.0-alpha to before 2.0.0-rc.3; 2.1.0-dev.0 to before 2.1.0-preview Fixed in 1.7.0, 2.0.0-rc.3, 2.1.0-preview Patch available CNA
Remediation
Upgrade the openvm package to version 1.7.0 in the 1.x line, 2.0.0-rc.3 in the 2.0 line, or 2.1.0-preview in the 2.1 line. CISA KEV does not list this vulnerability.
Written with Claude Haiku 5.5 from the sources below · 2026-10-30
- Fix · CNA openvm (openvm-org) Fixed in 1.7.0, 2.0.0-rc.3, 2.1.0-preview
Timeline
- 2026-10-30 Threatist record created from CVE-2026-62335
- 2026-11-01 Priority changed: MEDIUM → LOW
- 2026-11-06 CISA SSVC decision points changed
References
Other 9
- https://github.com/openvm-org/openvm/security/advisories/GHSA-w82q-w67c-67wv
- https://github.com/openvm-org/openvm/pull/152
- https://github.com/openvm-org/openvm/commit/1962276254aabc5420de266a8cb672433ce955ff
- https://github.com/openvm-org/openvm/blob/v2.0.0-alpha/crates/sdk/contracts/template/OpenVmHalo2Verifier.sol
- https://github.com/openvm-org/openvm/blob/v2.0.0-beta.2/crates/sdk/contracts/template/OpenVmHalo2Verifier.sol
- https://github.com/openvm-org/openvm/blob/v2.1.0-dev.0/crates/sdk/contracts/template/OpenVmHalo2Verifier.sol
- https://github.com/openvm-org/openvm/releases/tag/v1.7.0
- https://github.com/openvm-org/openvm/releases/tag/v2.0.0-rc.3
- https://github.com/openvm-org/openvm/releases/tag/v2.1.0-preview
More openvm-org vulnerabilities
- TI-2026-83375 Proof verification bypass in OpenVM Halo2 Solidity verifier CVSS 4.0HIGH 8.7
- TI-2026-83374 OpenVM MemoryMerkleAir lets forged rows change the memory root CVSS 4.0HIGH 8.7
- TI-2025-29394 OpenVM byte decomposition of pc in AUIPC chip can overflow CVSS 4.0HIGH 7.8
Sources
This product uses the NVD API but is not endorsed or certified by the NVD. Sources and licences