OpenVM CVE-2026-62334

Exploitation requires that the target application deployed the Solidity verifier wrapper generated by an affected OpenVM version (before 1.7.0 in 1.x, or affected 2.0/2.1 prereleases) and calls OpenVmHalo2Verifier.verify to gate trust. The concrete trigger is attacker control of the first four bytes of proofData so they match a non-verifier external selector exposed by the same wrapper contract (notably the extra public getter selector that the fix removes); in a correct proof those four bytes are part of the first KZG accumulator limb and must be zero. Limiting factors: the vulnerability is confined to deployments using the generated wrapper, and the fix neutralizes it both by removing the collidable getter selector and by adding a defensive check that the first four proof bytes are zero before the self-call. No authentication or user interaction is required per CVSS (PR:N/UI:N), but there is no impact on confidentiality or availability.

The CVSS 4.0 score of 8.7 (High) is driven by AV:N/AC:L/AT:N/PR:N/UI:N with VI:H and VC:N/VA:N - meaning a remote, unauthenticated attacker can forge proof acceptance with low complexity, impacting integrity only (no confidentiality or availability loss). This is consistent with the advisory: a malformed proof can bypass the Halo2 fallback verifier, letting the wrapper accept arbitrary app commitments and public values. The vuln.today Decision label is 'this_week', indicating meaningful but not emergency urgency. Key signals are MISSING: no EPSS score was provided, there is no CISA KEV listing, and no working exploit code is referenced (the GitHub links are the fix commit, PR #151, release tags, and the GHSA advisory - patch/advisory material, not a published exploit). The CVSS integrity-only profile directly CONTRADICTS the single input Tag 'Information Disclosure': with VC:N this is a proof-verification/integrity bypass, not a confidentiality issue - treat the tag as unreliable. Real-world priority is moderated by low deployment footprint (OpenVM is a niche zkVM framework) and by the precondition that the victim must have deployed the generated Solidity verifier wrapper on-chain; however, for any affected deployment the impact is severe because the entire zero-knowledge proof trust assumption is defeated.

An attacker interacting with a smart-contract application that deployed the generated OpenVmHalo2Verifier wrapper crafts proofData whose first four bytes collide with another external selector exposed by the wrapper. Calling verify triggers a staticcall to address(this) that dispatches to the benign non-verifier function, which returns successfully, so the wrapper accepts a forged proof and arbitrary app commitments/public values without ever running the Halo2 verifier. No public working exploit is referenced, but the GHSA advisory describes the mechanism in enough detail to reconstruct it, and the attack is remote and unauthenticated (AV:N/PR:N/AC:L).