OpenVM における重大な健全性バグ「CVE-2026-46669」の発見と修正：AI アウディター「zkao」による検証報告

本シリーズ第 2 回として、OpenVM の zkVMを対象に AI アウディター「zkao」を実行し、重大な脆弱性を特定しました。

発見された問題と概要

問題の性質

• 対象箇所:

  openvm-pairing

  ライブラリ内のペアリングチェック機能。
• バグ内容: 悪意のあるプロバー（証明者）が、任意のペアリング等式を偽造できてしまう致命的な健全性バグです。
  • これは zkVM の証明システム自体の欠陥ではなく、脆弱なライブラリを使用するコードのみに影響します。
• 対策状況:
  • CVE ID:

    CVE-2026-46669

  • 修正バージョン: OpenVM 1.6.0
  • 現状: 判明している限り、すべてのパートナー企業が当該バージョンへのアップグレード済みです。

発見までのプロセス

zkao

バグ 1: スケールファクターに対する部分体チェックの欠落

技術的背景

• ペアリングとは: Groth16、PLONK、BLS 署名などの基盤となる双線型写像 $e : G_1 \times G_2 \to G_T$ です。
• 検証ロジック: プロバーは偽のペアリング積を「1 に等しい」と見せかけることで、検証者を欺きます。
• Novakovic と Eagen の論文に基づく最適化:
  • 高価な最終指数付け（Final Exponentiation）を回避するため、代わりの関係式をチェックします。
  • オプティマイズ方程式: $f \cdot u = c^\lambda \wedge u^{d^i} = 1$
    • $u$: スケールファクター（Scaling Factor）
    • 必須条件: $u$ は部分体 $\mathbb{F}{p^6} \subset \mathbb{F}{p^{12}}$ に属する必要があります（奇数番の係数がゼロ）。

バグの詳細

• 欠陥: コードはヒント

  c

  がゼロでないことを確認するだけであり、スケールファクター

  u

  が部分体 $\mathbb{F}_{p^6}$ に属しているかのチェックを省略していました。
  • 修正前のコード (BLS12-381):

    // guest-libs/pairing/src/bls12_381/pairing.rs
    let (c, s) = Self::pairing_check_hint(P, Q);
    // ... s が Fp6 に属しているかのチェックなし ...
    let c_conj = c.conjugate();
    if c_conj == Fp12::ZERO {   // これだけでは c == 0 をのみ拒絶する
        return None;
    }
    

• 悪用手法:
  • プロバーは以下のように $u$ と $c$ を設定できます。 $$ c = 1, \qquad u = f^{-1} $$
  • これにより、チェックされる関係式 $f \cdot f^{-1} = 1 = c^\lambda$ が成立し、偽造されたペアリングが「正当」と判断されてしまいます。
  • 通常、$f^{-1}$ はフル $\mathbb{F}_{p^{12}}$ の要素であり、部分体チェックがないため拒絶されません。

影響範囲

このバグは以下のシステムを破壊します：

• KZG オープニング証明: データ可用性や Blob 検証の破綻。
• Groth16 SNARK 検証者: BLS 署名チェックなどの機能停止。
• zkVM ゲストエミュレーション: Ethereum の

  ecPairing

  アドレス（0x08）を実装するすべての zkVM ゲストが偽造結果を生成し、誤った EVM 実行を引き起こします。
  • L2 ロールアップ、ブリッジ、プライバシープロトコルも影響を受けます。

修正内容

• 対策: スケールファクターの奇数番の係数がゼロであることを強制するチェックを追加。
  • 修正後のコード:

    // スケールファクターが Fp6 の部分体に属している場合のみ「誠実なヒント（honest hint）」となる
    for i in [1, 3, 5] {
        if s.c[i] != Fp2::ZERO {
            return None;
        }
    }
    

• コミット:

  a720e2c

• リリース: OpenVM 1.6.0

実験から得られた教訓と今後の展望

LLM とエージェントの限界

• 単純な LLM の壁: OpenVM のような複雑なコードベースでは、モジュール間の依存関係を捉えきれず、「Informative（参考情報）」なレポートしか生成できませんでした。
  • zkVM は単独の関数ではなく、複数のモジュールが密に結合されているため、並列監査や単純なファイルパス渡しが機能しないのです。
• zkao の必要性:
  • 専門家の監査フローをコード化した

    cryptopsy

    フローにより、バグを発見しました。
  • ただし、Tri age（選別）プロセスでは LLM に PoC を生成させるだけでは不十分です。LLM は無意味なコメントやモックデータだけで偽の PoC を生成しやすく、人間による最終検証が不可欠であることが分かりました。

チームへの謝辞

• OpenVM チームへ迅速な対応と修正への感謝。
• 貴重なフィードバックを提供した Axiom の Yi Sun 氏へ感謝。

次のステップ

• 継続的な公開: 他のプロジェクトのバグ解決事例とともに、AI アウディティングの有効性・限界、必要な人間レビューの重要性について発信し続けます。
• 参加方法:
  • zkVM や暗号化プロジェクトの開発者の方々は、リリース前の重大なバグを早期に発見・修正されるよう、zkao と共に調査したいです。
  • ご関心がある方は、zksecurity.xyz/contact までお気軽にご連絡ください。