OpenVM's OpenVmHalo2Verifier self-call can bypass proof verification

openvm · CWE-754 · CWE-754

Affectedopenvm

FixNo fix listed yet.

PublishedOct 30, 20:06 · GitHub_M

ScoredOct 30 · 8.7 · GitHub_M

Exploit code publicNone known · checked 21:18 UTC

ExploitedNone known · CISA KEV checked 22:07 UTC

What we know

No known exploitation. CISA KEV, checked 22:07 UTC.

No public exploit code known. Exploit-DB, Metasploit, Nuclei, checked 21:18 UTC.

An attacker only needs network access to the target. No login needed. CVSS: network, no privileges.

A successful attack can change data. CVSS impact.

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

From GitHub_M

Affected and fixed versions

ProductAffectedFixed inopenvm< 1.7.0–openvm>= 2.0.0-alpha, < 2.0.0-rc.3–openvm>= 2.1.0-dev.0, < 2.1.0-preview–

Exploit code

Exploit-DBnone knownMetasploitnone knownNucleinone known

References

Other CVEs in openvm

All 4 →

8.7OpenVM: MemoryMerkleAir allows below-leaf rows to alter memory roots · CVE-2026-62333Oct 30 6.9OpenVM's OpenVmHalo2Verifier accepts non-canonical app commitments · CVE-2026-62335Oct 30 8.7`openvm-pairing` pairing check missing proper subfield check on scaling factor · CVE-2026-46669Jun 10