CVE-2026-62335 in OpenVM
Summary
by MITRE • 10/30/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/30/2026
The vulnerability identified within OpenVM prior to version 1.7.0 and in specific pre-release versions of the 2.x line stems from a critical input validation failure at the Solidity wrapper boundary, specifically affecting the `OpenVmHalo2Verifier.verify` function. This zero-knowledge virtual machine framework relies on cryptographic proofs generated over the BN254 elliptic curve group to ensure computational integrity and privacy. The core technical flaw lies in the handling of two specific parameters: `appExeCommit` and `appVmCommit`. These values are accepted as raw 32-byte arrays, representing 256-bit unsigned integers, without any verification that they conform to the canonical representation required by the underlying BN254 scalar field. In elliptic curve cryptography using pairing-based proofs like those in Halo2, inputs must be reduced modulo the prime order of the group, known as the scalar field modulus. By accepting raw byte values directly, the system fails to enforce this mathematical constraint, allowing callers to supply non-canonical encodings that are numerically greater than or equal to the BN254 scalar field modulus.
This lack of canonicalization introduces a significant ambiguity between the literal byte-level data provided by the caller and the actual field elements processed by the zero-knowledge verifier. While the wrapper correctly validates the lengths of public values and proof data, it neglects the semantic validity of the commitment hashes themselves. In cryptographic protocols, non-canonical inputs can lead to undefined behavior or incorrect verification outcomes depending on how the underlying library handles out-of-range integers. If the implementation simply truncates or wraps these values without explicit validation, an attacker could potentially exploit this discrepancy. Although BN254 is a prime-order group which mitigates some subgroup attack vectors common in composite-order groups, the acceptance of non-canonical inputs violates best practices for secure cryptographic interface design and can lead to inconsistencies between different implementations or future updates that might strictly enforce canonical forms.
The operational impact of this vulnerability centers on the integrity of proof verification within decentralized applications utilizing OpenVM. Applications relying on this wrapper may inadvertently accept proofs associated with invalid commitment hashes, potentially leading to false positives in verification processes where a malicious actor could attempt to manipulate state transitions or data commitments by exploiting the gap between raw byte representation and field element arithmetic. This flaw aligns with CWE-20 Improper Input Validation, as the system fails to verify that input values meet all necessary constraints before processing them through cryptographic routines. Furthermore, it relates to CWE-754 Improper Check for Unusual or Exceptional Conditions, specifically regarding out-of-range inputs in a security-critical context. From an ATT&CK perspective, this represents a weakness in the implementation of cryptographic mechanisms that could be leveraged during exploitation phases involving tampering with data integrity checks on blockchain networks.
To mitigate this vulnerability and ensure robust security posture, it is imperative to upgrade OpenVM to version 1.7.0 or later, which includes patches for versions 2.0.0-rc.3 and 2.1.0-preview that address these input validation gaps. For systems unable to immediately update, developers should implement strict canonicalization checks at the application layer before passing `appExeCommit` and `appVmCommit` to the verifier. This involves verifying that each byte array represents a value strictly less than the BN254 scalar field modulus, typically by checking if the most significant bits exceed certain thresholds or by performing modular reduction explicitly in Solidity using safe arithmetic libraries. Adhering to these practices ensures that all inputs conform to the mathematical expectations of the underlying zero-knowledge proof system, thereby eliminating ambiguity and preventing potential exploitation through non-canonical input manipulation.