Live › vulnerability › CVE-2026-62333
OpenVM, a zero-knowledge virtual machine framework, does not reject certain Merkle expansion rows in its memory air, so a malicious prover can change committed memory without a matching memory operation. The result is that OpenVM proofs can be made to attest to memory state that was never legitimately computed.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-30 20:25 UTC. All times on this page are UTC.
Teams that build or run OpenVM provers or verifiers on versions before 1.7.0 or on the affected 2.0 and 2.1 prereleases. The sources describe soundness of proofs that use persistent memory across continuation segments, so teams relying on OpenVM proofs for trust decisions are the ones who matter. Teams on fixed versions, or not using OpenVM, can skip it.
No product ranges from the sources yet.
cargo tree | grep openvm in the project.1.7.02.0.0-rc.32.1.0-previewEach row is the first time that source carried this signal. The analyst’s rows are its own findings.
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, MemoryMerkleAir does not forbid Merkle expansion rows at parent_height = 0 or below while expand_direction != 0. A malicious prover can fabricate a subtree below a memory leaf and swap digests inside that subtree to change the committed memory root without a corresponding memory operation. The fraudulent rows still balance against the Merkle and compression buses and require no memory-bus operation for the changed leaf. Because the memory Merkle root binds VM memory state across continuation segment boundaries, this affects the soundness of OpenVM proofs using persistent memory. This issue is fixed in versions 1.7.0, 2.0.0-rc.3 and 2.1.0-preview.
This page as .md · .json · in your agent: get_signal("CVE-2026-62333")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.