OpenVM CVE-2026-46669

Exploitation requires that a downstream system actually invokes openvm-pairing's try_honest_pairing_check on attacker-influenced inputs - i.e., the target must be a verifier or proof-consuming application built on OpenVM pre-1.6.0 that performs Fp12 pairing checks via this specific function. The attacker must control the scaling factor s passed into the pairing optimization (typical for a malicious-prover threat model in zkVM workflows) and must possess the pairing-cryptography skill to choose an s outside every proper subfield of Fp12 while still satisfying the rest of the proof structure. No authentication, user interaction, or special platform is required by the library itself (consistent with CVSS PR:N/UI:N), but the attack surface is limited to systems that (a) use openvm-pairing, (b) are on a pre-1.6.0 release, and (c) treat pairing-check success as a trust boundary; deployments that only use OpenVM for non-pairing circuits or that have already pinned v1.6.0 are not exposed.

The CVSS 4.0 vector (AV:N/AC:L/PR:N/UI:N/VI:H) and 8.7 score reflect a network-reachable, low-complexity, unauthenticated integrity-only attack - which fits the threat model of a malicious prover submitting forged proofs to a verifier. However, the practical risk depends heavily on whether downstream applications actually use the openvm-pairing guest library for security-critical pairing verifications (e.g., BLS signature aggregation, bridge proofs, rollup verification), so the population of exploitable deployments may be narrower than the network vector suggests. There is no CISA KEV listing, no EPSS score provided, and no public POC identified, consistent with a recently disclosed zkVM soundness bug requiring cryptographic expertise rather than off-the-shelf exploitation. The AC:L rating arguably understates difficulty - constructing an out-of-subfield scaling factor that produces a useful forged proof requires non-trivial pairing-cryptography knowledge - but the integrity consequences (accepted-but-invalid proofs) are severe for any consumer relying on OpenVM-generated proofs for trust.

A malicious prover targeting a verifier that consumes OpenVM-generated pairing proofs (for example a rollup, bridge, or signature-verification service) constructs an Fp12 element s that lies outside any proper subfield, uses it as the scaling factor in the optimized pairing equality, and produces a proof claiming a pairing relation that does not actually hold. The verifier, running pre-1.6.0 openvm-pairing, accepts the proof as valid, allowing the attacker to spoof a signature, forge a state transition, or otherwise have false claims accepted as cryptographically attested. No public exploit identified at time of analysis, but the underlying paper (eprint 2024/640) describes exactly the theorem whose preconditions are being violated, lowering the research cost for a determined attacker.