---
id: "CVE-2026-62335"
kind: "vulnerability"
aliases: ["CVE-2026-62335"]
title: "OpenVM: Solidity verifier accepts non-canonical commitments, creating verification ambiguity"
severity: "medium"
cvss: 6.9
epss: null
exploited: false
status: "open"
category: "package"
products: []
ecosystems: []
tags: ["ethereum", "openvm", "package", "solidity", "zkvm"]
not_affected_if: ["hard-coded-commitments", "off-chain-only"]
published_at: "2026-10-30T20:17:12+00:00"
first_seen_at: "2026-10-30T20:25:39+00:00"
updated_at: "2026-10-30T20:26:45+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-62335", "first_seen_at": "2026-10-30T20:25:39+00:00"}]
---

# OpenVM: Solidity verifier accepts non-canonical commitments, creating verification ambiguity

OpenVM's Solidity verifier contract OpenVmHalo2Verifier.verify accepts appExeCommit and appVmCommit values without checking they are below the BN254 field modulus. An attacker can supply non-canonical 256-bit encodings of the same field element, so applications relying on the wrapper may accept commitments that differ at the byte level from the values the verifier actually uses.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Check whether the project depends on OpenVM (`openvm` crate or the OpenVM Solidity verifier contracts) and which version is pinned in the lockfile or `Cargo.toml`.
- Look for calls to `OpenVmHalo2Verifier.verify` in your Solidity contracts and check whether the app commitments are trusted from callers or hard-coded.
- Confirm the OpenVM version in use is below `1.7.0`, or is `2.0.0-rc.1`/`2.0.0-rc.2`/`2.1.0` prerelease builds before the fixed prereleases.

## Fix

- OpenVM `1.7.0` or later
- OpenVM `2.0.0-rc.3` or later
- OpenVM `2.1.0-preview` or later

## Timeline

- 2026-10-30T20:25:39+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-62335

## From the sources

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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_