AI Meets Cryptography 2: What AI Found in OpenVM's ZkVM

By Stefanos Chaliasos and Hao Pham Published: July 17, 2026 | Reading Time: ~13 min security crypto AI zkao audit zkvm

---

This article serves as the second installment of our series. If you missed the first part regarding Cloudflare's CIRCL, I recommend reading it for a deeper understanding of our experimental goals and the architecture of our pipeline.

In this session, we deployed zkao—our specialized AI security auditor—against the OpenVM zkVM. The result was the discovery of a critical soundness vulnerability within the openvm-pairing guest library. This flaw allowed a malicious prover to successfully forge any pairing equality.

[!IMPORTANT] Clarification on Scope: This was not a flaw in the zkVM's core proving system. Instead, the vulnerability resided specifically in the guest library code used by developers.

Resolution and Impact

The vulnerability has been formally documented as CVE-2026-46669 and was resolved in OpenVM version 1.6.0. To the best of our knowledge, all partners utilizing OpenVM have already migrated to the patched version.

A Note on the Process: As with our previous experiment, the AI did not generate a final, polished audit report. Instead, it produced a candidate finding. Our human experts then performed the following:

• Validated the technical issue.
• Confirmed the exploitability of the bug.
• Analyzed the full impact on affected projects.
• Managed the coordinated disclosure process.

Because zkao provided a detailed report and a minimal Proof of Concept (PoC), the manual triage was exceptionally fast.

---

The Journey to Discovery

Our process began four months ago with a standard scan of OpenVM. Initially, we followed our baseline protocol:

1. Use a general LLM with a basic prompt.
2. Use an LLM augmented with our proprietary, expert-maintained skill sets.

Even after the release of Opus 4.7 and Codex 5.4, the results were underwhelming. While the models identified several "Critical" or "High" issues, none of them were actually exploitable they were merely valid observations without security impact.

The Complexity Hypothesis

We hypothesized that a zkVM is simply too intricate for a "naive" LLM setup, regardless of whether the context window is 300K or 1M tokens. The primary issue is the density of dependencies between modules.

Comparison of Audit Strategies

In a standard library, you can hand a subagent a specific folder, let it apply relevant skills, and have a main agent stitch the findings together. This works well with tools like Claude Code or Codex.

However, in a complex system like OpenVM, this "isolated" mode fails. You can have:

• Module A: Provably Secure
• Module B: Provably Secure
• Composition (A + B): $\text{Insecure}$

Therefore, the goal of a subagent should not be to find bugs, but to extract knowledge: What does this module assume? What does it delegate? What hidden invariants does it rely on?

The Context Engineering Challenge

The difficulty lies in the representation of this knowledge:

• Too brief $\rightarrow$ The implementation detail containing the bug is omitted.
• Too verbose $\rightarrow$ The main agent's context window overflows before synthesis occurs.

Current agentic coding tools do not solve this efficiently. Consequently, we decided to deploy zkao—which utilizes our custom context engineering and encoded expert workflows—despite our rule to only use it after plain LLMs had succeeded.

After over nine hours of analysis, zkao flagged a critical soundness bug in the pairing check of a guest library.

---

Bug Analysis: openvm-pairing

Summary Table

Note: In this instance, the AI's severity assessment aligned perfectly with the maintainers'.

Technical Background

Pairings are the fundamental mechanism powering protocols such as Groth16, PLONK (with KZG), and BLS signatures. In these systems, the verifier typically checks if a product of pairings equals one:

$\prod_i e(P_i, Q_i) = 1$

If a prover can manipulate this product to appear as $1$ when it is not, the entire soundness of the SNARK proof, KZG opening, or signature is compromised.

A pairing is defined as a bilinear map: $e : G_1 \times G_2 \to G_T$ Where $G_1, G_2$ are elliptic-curve groups and $G_T$ is a multiplicative subgroup of $\mathbb{F}_{p^{12}}^{*}$. The core utility comes from bilinearity: $e([a]P, [b]Q) = e(P, Q)^{ab}$

The Root Cause

The computation of a pairing $e(P, Q)$ generally involves two stages. The first is the evaluation of a Miller function $f_{r, Q}(P)$. For a product of pairings, the circuit computes these Miller loops and multiplies the results.

As noted in the research by Novakovic and Eagen, the outputs of Miller loops are not unique; they are unique only up to multiplication by a specific factor...