CVE-2026-62334 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` constructs raw proof calldata from user-controlled `proofData`, performs a `staticcall` to `address(this)`, and treats a successful call as proof acceptance. If the first four proof bytes match another external selector exposed by the wrapper, dispatch can invoke a successful non-verifier function instead of the generated Halo2 fallback verifier. Applications using the generated Solidity wrapper can consequently accept arbitrary app commitments and public values without checking the proof suffix, accumulator, app commitments or public values. This issue is fixed in versions 1.7.0, 2.0.0-rc.3 and 2.1.0-preview.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/30/2026
The vulnerability identified within OpenVM, a modular zero-knowledge virtual machine framework, represents a critical logic flaw in the cryptographic verification process of its generated Solidity wrappers. Specifically affecting versions prior to 1.7.0 in the 1.x line and certain prereleases of version 2.0 and 2.1, this issue stems from how the `OpenVmHalo2Verifier.verify` function handles incoming proof data. The core technical flaw lies in the construction of raw proof calldata derived directly from user-controlled input without sufficient validation against expected structural constraints before execution. When a verification request is made, the contract constructs call data and executes it via a staticcall to its own address. This mechanism relies on an implicit assumption that any successful return code indicates a valid cryptographic proof, rather than verifying that the executed function was indeed the intended Halo2 fallback verifier logic.
This architectural oversight creates a dispatch ambiguity where the first four bytes of the calldata act as a selector for internal functions within the contract. If these initial bytes coincidentally match an external selector exposed by the wrapper but belonging to a non-verifier function, the EVM will successfully execute that alternative function and return success. Consequently, the verification logic incorrectly interprets this successful execution of an unrelated or benign function as proof acceptance. This bypasses all subsequent cryptographic checks, including validation of the proof suffix, accumulator state, application commitments, and public values. The result is a complete failure of the zero-knowledge property guarantees, allowing any arbitrary data to be accepted as a valid proof without mathematical verification.
From an operational impact perspective, this vulnerability compromises the integrity of applications relying on OpenVM for trustless execution or verifiable computation. Since the system accepts arbitrary app commitments and public values as verified proofs, attackers can forge credentials, bypass access controls, manipulate state transitions, or trigger unauthorized financial transactions in decentralized finance protocols that integrate these vulnerable wrappers. The severity is exacerbated by the fact that this is a logic error rather than a simple buffer overflow; it exploits the contract's own dispatch mechanism to subvert security assumptions. This aligns with CWE-287, which describes Improper Authentication, as well as CWE-94, Code Injection, insofar as user-controlled input dictates execution flow leading to unauthorized state changes. In terms of MITRE ATT&CK techniques for blockchain and smart contracts, this scenario reflects patterns associated with improper validation of inputs leading to privilege escalation or integrity violation, often categorized under exploitation of logic flaws rather than resource exhaustion.
Mitigation requires immediate upgrading to patched versions where the dispatch mechanism is hardened. Specifically, users must upgrade to OpenVM version 1.7.0 for the legacy line or version 2.0.0-rc.3 and later for newer releases. The fix involves ensuring that only calls intended for the specific Halo2 verifier function are processed as valid proofs, likely by implementing stricter checks on calldata structure or using a more robust dispatch pattern that prevents selector collisions with other contract functions. Developers should also audit their integration points to ensure no reliance on return codes from staticcalls without explicit verification of the executed code path. Regular security audits focusing on cryptographic implementation details and smart contract logic flows are essential to prevent similar issues in future iterations, ensuring that proof validation remains isolated and resistant to selector-based bypasses.