OpenVM zkVM Bug—AI Auditor Found a Critical Proof Flaw
An AI security agent found a critical soundness bug in OpenVM's zkVM pairing library, letting attackers forge zero-knowledge proofs until the 1.6.0 patch.
In Brief
- A security agent built by ZK Security found a critical soundness bug in OpenVM’s zkVM that let a malicious prover forge pairing checks.
- The flaw sat in a guest library, openvm-pairing, not in the zkVM’s core proving system, so only projects that verify elliptic-curve pairings were exposed.
- Tracked as CVE-2026-46669 and fixed in OpenVM 1.6.0, the bug needed more than 9.5 hours of AI scanning before it surfaced.
An AI security agent found a critical flaw in OpenVM’s zkVM that let a malicious prover forge pairing checks and break the soundness of zero-knowledge proofs built on top of them.
The finding comes from ZK Security‘s running experiment of pointing AI at open-source cryptography. Their auditor, called zkao, flagged the issue after more than 9.5 hours of scanning OpenVM, and the team’s humans then validated it and handled disclosure. It is the second time this year an AI agent has upstaged traditional review — earlier, Mythos AI surfaced a 27-year-old OpenBSD bug that fuzzing missed.
Plain large language models had already hit a wall on this codebase. ZK Security ran Opus 4.6 and Codex 5.3 against OpenVM, then re-ran the newer Opus 4.7 and Codex 5.4 builds, and while the models confidently labeled findings Critical or High, none were actually exploitable. zkao, with expert-coded audit flows, was what finally caught the real defect.
What the OpenVM zkVM bug actually was
Pairings are the engine under Groth16, PLONK with KZG, and BLS signatures, where a verifier asks one question: does a product of pairings equal one. OpenVM sped this check up with the residue-witness trick from Novakovic and Eagen’s paper, letting the prover hand in a scaling factor instead of running an expensive final exponentiation inside the circuit.
The optimization is sound only if that scaling factor stays inside a specific subfield of the 12-degree extension field, Fp6. OpenVM, an open-source zkVM framework hosted on GitHub, checked that the prover’s hint was non-zero and stopped there — it never confirmed the scaling factor sat in the right subfield. The fix commit added the missing three equality checks on the odd-indexed coefficients of the scaling factor.
The forgery is almost embarrassingly simple once the check is gone. For any Miller-loop output, even one from a false pairing equation, a prover sets the hint to 1 and the scaling factor to its inverse, and the circuit accepts the relation as true. Both the BN254 and BLS12-381 code paths had the same gap, and zkao rated the bug Critical, a severity the OpenVM maintainers confirmed.
Why a forged pairing check rattles zero-knowledge security
A forgeable pairing check collapses the cryptographic floor under a lot of systems. On BLS12-381 it lets a prover fake KZG opening proofs, which back data availability, blob verification, and PLONK or KZG verifiers, while on BN254 it breaks Groth16 SNARK verifiers, BLS signatures, and pairing-based bridges.
Any zkVM guest that emulates Ethereum’s ecPairing precompile at address 0x08 through OpenVM’s check would return forged results and run incorrect EVM logic. That places L2 rollups, bridges, and privacy protocols that verify pairings inside an OpenVM guest program at risk, the same class of Ethereum infrastructure that secures billions in settled value.
NVD lists the flaw as CVE-2026-46669 with a 7.5 HIGH CVSS v3.1 score and classifies it as CWE-20, improper input validation, with the patch shipped in OpenVM 1.6.0. OpenVM is an open-source, modular zero-knowledge virtual machine framework written in Rust that lets developers prove a program ran correctly. The bug lived in its openvm-pairing guest library, which handles elliptic-curve pairing checks for SNARK and KZG verification. Pairing checks underpin SNARK verifiers, KZG commitments, and BLS signatures, so a forged check makes a false proof look valid. Any protocol verifying pairings inside an OpenVM guest, from rollups to bridges to privacy tools, could be tricked until the 1.6.0 fix landed. ZK Security plans to keep publishing confirmed bugs from other projects as they are resolved and is offering continuous AI coverage through zkao. The team stresses that humans still validate every candidate finding and handle disclosure, so the agent is a triage tool rather than a solo auditor.
FAQ
What is OpenVM’s zkVM?
Why does a pairing bug matter for zero-knowledge proofs?
What comes next for AI-assisted crypto audits?
