Which versions of OpenVM are affected by EUVD-2026-36121?

OpenVM's openvm-pairing library prior to version 1.6.0 contains a critical integrity flaw that allows attackers to forge zero-knowledge proofs that pass validation checks despite being mathematically…. A patch is available.

How to fix or mitigate EUVD-2026-36121?

Within 24 hours: Inventory all systems and services running OpenVM versions prior to 1.6.0. Within 7 days: Update to OpenVM v1.6.0 (vendor-released patch). Within 30 days: Complete end-to-end testing of the patched version in production environments and validate that proof verification now correctly rejects invalid proofs.

OpenVM EUVD-2026-36121

Q: What is the CVSS score of EUVD-2026-36121?

EUVD-2026-36121 has a CVSS 4.0 base score of 8.7 (High). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.1%.

| CVE-2026-46669 HIGH

Improper Input Validation (CWE-20)

2026-06-10 GitHub_M

Information Disclosure Openvm

8.7

CVSS 4.0 · Vendor: GitHub_M

Severity by source

Vendor (GitHub_M) PRIMARY

8.7 HIGH

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

vuln.today AI

5.9 MEDIUM

Remote malicious prover can submit forged proofs (AV:N, PR:N, UI:N); crafting an out-of-subfield Fp12 scaling factor requires pairing-cryptography expertise (AC:H); only proof integrity is impacted (I:H, C:N, A:N).

3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N

Primary rating from Vendor (GitHub_M).

CVSS VectorVendor: GitHub_M

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Lifecycle Timeline

Patch available

Jun 10, 2026 - 22:01 EUVD

Source Code Evidence Fetched

Jun 10, 2026 - 21:16 vuln.today

Analysis Generated

Jun 10, 2026 - 21:16 vuln.today

DescriptionCVE.org

OpenVM is a performant and modular zkVM framework built for customization and extensibility. Prior to version 1.6.0, the openvm-pairing guest library's try_honest_pairing_check function invokes Theorem 3 of https://eprint.iacr.org/2024/640.pdf but does not check that the scaling factor s is in a proper subfield of Fp12. This allows incorrect results to the pairing check. This issue has been patched in version 1.6.0.

AnalysisAI

Pairing soundness flaw in OpenVM's openvm-pairing guest library prior to version 1.6.0 allows attackers to produce zero-knowledge proofs that pass a pairing check despite being mathematically invalid, because the try_honest_pairing_check function fails to verify that the scaling factor s lies in a proper subfield of Fp12 as required by Theorem 3 of eprint 2024/640. The vulnerability carries an 8.7 CVSS 4.0 score with high integrity impact and no confidentiality or availability impact, and no public exploit identified at time of analysis. The vendor patched it in OpenVM v1.6.0 as part of a coordinated security release addressing four advisories.

Technical ContextAI

OpenVM is a modular zkVM (zero-knowledge virtual machine) framework, and openvm-pairing is its guest library for elliptic-curve pairing operations used in cryptographic verification. Pairings map points on elliptic curves into the extension field Fp12, and the optimization in eprint 2024/640 Theorem 3 reduces an Fp12 equality check to a scaled comparison - but the theorem only holds when the scaling factor s belongs to a proper subfield of Fp12. By omitting this subfield membership check, OpenVM violates the theorem's precondition, which under CWE-20 (Improper Input Validation) means a malicious prover can choose an s outside the subfield that makes the pairing equation falsely satisfy. CPE coverage is cpe:2.3:a:openvm-org:openvm:*:*:*:*:*:*:*:* with all pre-1.6.0 versions in scope.

RemediationAI

Vendor-released patch: OpenVM v1.6.0. Upgrade to v1.6.0 or later (release notes at https://github.com/openvm-org/openvm/releases/tag/v1.6.0), which adds the missing subfield check to try_honest_pairing_check and also bundles fixes for three other advisories (GHSA-9jfx-4f4f-497j, GHSA-j9m2-fxc5-fr82, GHSA-fh29-29h9-qm9h) plus the upstream Plonky3 0.4.3 transcript-binding fix, so the same upgrade closes multiple soundness gaps. If upgrading immediately is not feasible, the only meaningful compensating control is to avoid relying on openvm-pairing pairing checks for security-critical decisions (e.g., do not accept proofs whose verification depends on this code path in production) and to treat any pairing-based attestations produced by older versions as untrusted; there is no runtime configuration toggle, since the missing constraint is in the circuit logic itself. Full advisory details are at https://github.com/openvm-org/openvm/security/advisories/GHSA-76mq-v757-53gr.