<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>VulnFeed.org: openvm-org openvm</title><link>https://vulnfeed.org/</link><description>Every disclosure, as it lands. Critical-only feed available.</description><language>en</language><atom:link href="https://vulnfeed.org/feed/product/openvm-org-openvm.xml" rel="self" type="application/rss+xml"/><item><title>CVE-2026-62333: OpenVM: MemoryMerkleAir allows below-leaf rows to alter memory roots</title><link>https://vulnfeed.org/cve/CVE-2026-62333/</link><guid isPermaLink="true">https://vulnfeed.org/cve/CVE-2026-62333/</guid><pubDate>Fri, 30 Oct 2026 20:17:12 +0000</pubDate><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, `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.</description></item><item><title>CVE-2026-62334: OpenVM&apos;s OpenVmHalo2Verifier self-call can bypass proof verification</title><link>https://vulnfeed.org/cve/CVE-2026-62334/</link><guid isPermaLink="true">https://vulnfeed.org/cve/CVE-2026-62334/</guid><pubDate>Fri, 30 Oct 2026 20:17:12 +0000</pubDate><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.</description></item></channel></rss>
