イーサリアムのバリデータ停止を招く脆弱性「CVE-2026-34219」が公開、AIが発見し人間が検証
2026年7月13日 16:16
イーサリアムのコンセンサスクライアントやバリデータ、またはRust版の「libp2p-gossipsub」を基盤とするアプリケーションを運用する管理者は、直ちにバージョン0.49.4以降へのアップグレードが必要だ。2026年7月9日に公開された高深刻度の脆弱性（CVE-2026-34219）により、認証されていないネットワーク上のピアが、細工したメッセージを1通送信するだけでプロセス全体を強制終了（クラッシュ）させられる状態にあったことが判明した。このバグは協調型のAIエージェントによって発見され、人間の専門家によって検証・確認された。
■1通のメッセージでクラッシュ：PRUNEバックオフバグの仕組み
gossipsubプロトコルは、制御メッセージを用いてノード間の接続を管理している。その一つである「PRUNE」メッセージは、接続相手のピアに対して指定された時間だけ接続を控える（バックオフする）よう指示するもので、ネットワークの維持管理において日常的に使われている。
今回の脆弱性は、このPRUNEメッセージを処理するハンドラに存在する。リモートのピアが、表現可能な最大値に近いバックオフ期間の値を含むPRUNEメッセージを送信すると、gossipsubは境界チェック（バウンズチェック）を行わずにこれを受け入れ、Rustの時間型（Instant）の上限値に近い値として保存してしまう。その後、次のハートビート（定期処理）のタイミングで、未チェックのまま「Instant + Duration」の加算処理が行われ、算術オーバーフローが発生する。
Rust言語の仕様では、このようなオーバーフローが発生すると、誤った値をそのまま処理し続けるのではなく、パニック（例外による強制終了）を起こしてプロセス全体を終了させる。これにより、認証情報やセッション状態を持たない任意のgossipsubピアから、有効なプロトコル接続を介してメッセージを1通送るだけで、バリデータノードをオフラインにすることが可能となっていた。
攻撃者はノードが再起動するたびに接続し直して同じメッセージを再送するだけでよいため、極めて低いコストでサービス拒否（DoS）攻撃を繰り返し実行できる。バージョン0.49.4未満のRust版libp2p-gossipsubを実行しているバリデータ、インデクサー、サイドツールなどがこの影響を受ける。GitHubのセキュリティアドバイザリによると、この脆弱性はイーサリアムに限定されず、該当するRustクレートを本番環境で使用しているすべてのアプリケーションに及ぶという。
libp2p-gossipsub v0.49.4でリリースされたパッチでは、PRUNEメッセージ内のバックオフ期間の値がハートビート処理の演算に回される前に境界チェックを追加し、オーバーフローの経路を完全に遮断している。
■「Rust製」が防げること、防げないこと
今回のパッチノートが明示していない重要な事実がある。それは、Rustのメモリ安全性に関する保証が、この脆弱性の発生自体を防いだわけではないということだ。Rustは脆弱性の性質を変化させたに過ぎない。
CやC++の場合、ネットワークハンドラにおける未チェックの整数オーバーフローは、通常「未定義の動作」を引き起こす。プログラムが不正な値を密かに書き込んだり、隣接するメモリ領域を破壊したりして、攻撃者に任意のコード実行（RCE）を許す条件を与えてしまう可能性がある。一方、RustはRFC 560に基づき、整数オーバーフローが発生した場合は未定義の動作を起こさずにパニック（強制終了）するよう規定している。結果としてプロセスは終了（クラッシュ）するが、メモリ破壊やコード実行には至らない。
バリデータの運用者にとっては、ノードがオフラインになるという実質的な結果は同じである。しかし、セキュリティ評価の観点からはこの違いが重要となる。CVE-2026-34219は「サービス拒否（DoS）」の脆弱性であり、「リモートコード実行」や「データ流出」の脆弱性ではない。Rustの設計はバグの深刻度を抑制したものの、バグの存在自体を防ぐことはできなかった。
そのため、「Rust製だからリモートクラッシュ攻撃に対して安全である」と解釈している運用者がいれば、それは誤解である。メモリ安全性とクラッシュ安全性は異なる特性だ。検閲耐性を確保するために設計上すべての接続ピアに開かれているgossipsubの制御メッセージ処理領域は、入力値検証の不備が遠隔から悪用可能なパニックを引き起こしやすい場所であり続けている。
なお、今回のCVE-2026-34219は、同じPRUNEバックオフサブシステムに存在しv0.49.3で修正された高深刻度の脆弱性「CVE-2026-33040」に続くものである。連続するリリースで同じハンドラから2つの高深刻度バグが検出されたことは、これが単なる一過性の見落としではなく、gossipsubの制御メッセージ演算における検証構造そのものに弱点があることを示唆している。
■AIエージェントはいかにしてバグを発見し、何が「幻覚」だったのか
イーサリアム財団（EF）のプロトコルセキュリティチームは、米AnthropicのFrontier Red Teamの手法を参考にした。同チームは、Pythonエコシステム全体で実際のバグを発見したプロパティベースのテストエージェントを構築している。イーサリアムのシステムソフトウェア、暗号ライブラリ、コンセンサスレイヤーのスマートコントラクトに対し、複数のAIエージェントが並行して実行され、中央のディスパッチャーなしで共有Gitリポジトリを介して協調動作した。役割は事前に割り当てられず、調査の進展に伴って自律的に形成された。例えば、攻撃対象領域をテスト可能な仮説に変換する「偵察エージェント」、コードパスを追跡して再現環境を構築する「ハンティングエージェント」、テストカバレッジを追跡する「ギャップ補完エージェント」、そして報告前に候補を独自に検証する「検証エージェント」などだ。
従来のファズテスト（ファジング）との構造的な違いは、ツールが出力する成果物にある。ファザーはクラッシュログとスタックトレースを返すため、人間のエンジニアは障害が本物で到達可能かどうかを数分で判断できる。これに対し、AIエージェントは、バグへの到達経路を説明する文章、重要性の根拠、深刻度の評価、そして動作する概念実証（PoC）コードなど、人間が書いたセキュリティレポートのような成果物を出力する。そして、その文章は、対象のバグが本物であっても、存在しない「幻覚」であっても、同様に流暢に作成される。
この「出力の見た目の同等性」が、チームにとって最大の運用上の課題となった。エージェントは数百件の候補を生成したが、その大部分は実際のバグではなかった。しかも、出力が生のクラッシュログではなく、もっともらしい説明文であるため、誤検知（偽陽性）を退けることが非常に困難であった。
イーサリアム財団の事後分析によると、紛らわしい報告は主に3つのカテゴリに分類された。1つ目は、コンパイラの安全フラグが有効なデバッグビルドやテストビルドでのみ発生し、出荷用ソフトウェアには存在しないクラッシュ。2つ目は、単体では脆弱性に見えるが、外部からその値に到達するすべての経路がすでに保護されているため、攻撃者が手動で危険な値を埋め込む必要がある攻撃。3つ目は、自明な事実を証明するだけで、敵対的な条件下での実際のコードの挙動について意味のある情報を何も示さない形式検証の証明である。
イーサリアム財団のNikos Baxevanis氏は、これらを「実際には何もテストしていないテスト」と表現し、それらが本物のテストと全く同じ自信に満ちたトーンで書かれていたと指摘している。
AnthropicのFrontier Red Teamも同様の状況に直面しており、同チームのプロパティベースのテストエージェントが生成した約1,000件の候補レポートのうち、専門家の審査を通過したのは上位候補の約86%であったという。生成は高速に行われたが、その検証には膨大な時間がかかった。
イーサリアム財団のチームは、候補を実際のバグとして認定するための基準として、「出荷された実際のコードに対して障害を再現し、それを作成していない第三者の環境でも正常に動作する、自己完結型の再現コード（レプロデューサー）」を求めた。CVE-2026-34219はこの基準をクリアした。
■現在のAIエージェントが依然として見落とす領域
現在のAIセキュリティエージェントの推論能力には構造的なギャップが存在しており、それは直近で発生した多額の被害を伴うDeFi（分散型金融）のハッキングパターンと直接重なっている。
AIエージェントは、コード実行のある一瞬に存在する脆弱性（境界チェックの欠落、未チェックの算術演算、特定の値でバイパスできるガードなど）の特定には優れている。しかし、個々のステップはすべて正当であるものの、その実行順序によって悪意のある結果がもたらされるような、一連のシーケンスにまたがる攻撃の追跡は苦手としている。
直近の2週間で発生した2つの大規模なDeFi攻撃がこのパターンに該当する。7月1日のEdel Financeにおけるフラッシュローン攻撃では、Chainlinkの価格オラクルはGoogleの株価を約357ドルと正しく報告していた。脆弱性はトークン化された株式とそのラップ版との間の内部交換レートにあり、攻撃者はフラッシュローンを使ってこれを約78倍に膨らませ、架空の担保に対して実際の資産を借り入れ、約40万3,000ドル（約6,529万円、1ドル=162円換算）の不良債権を残した。また、7月6日のBonkDAOに対するガバナンス攻撃では、トークンの購入、投票、財務プールからの送金はすべてオンチェーン上で正当なトランザクションであった。攻撃者はBONKの供給量の約1%を取得し、財務プールからの送金提案を提出し、1万8,000人以上のメンバーのうちわずか7つのウォレットの定足数で可決させ、約2,000万ドル（約32億4,000万円、1ドル=162円換算）を流出させた。
どちらの攻撃も、単一の不正な値をスキャンするシステムでは検知できなかった。全体の効果として有害となる、一連の合法的な操作のシーケンスを追跡する必要があったためだ。
このギャップに対するイーサリアム財団の現在の対策は、AIエージェントにテストすべき不審なシーケンスを提案させ、そのシーケンスに対して従来の検証インフラを実行するというアプローチだ。つまり、「エージェントが提案し、人間と決定論的なツールが決定する」という役割分担である。
様々なモデルで実際の脆弱性をテストしたStanislav Fort氏は、AIの能力分布を「ギザギザのフロンティア（jagged frontier）」と表現している。あるコードベースで完全な攻撃チェーンを復元できたエージェントが、別のコードベースでは基本的なデータフローの追跡に失敗することもあるという。
■システムソフトウェアへの移行が意味すること
これまでのイーサリアムにおけるAI支援型のセキュリティ研究は、ほぼすべてスマートコントラクト（EVM上で動作し、明確な金融ロジックを扱い、通常は限定された入力セットと相互作用するコード）に焦点を当てていた。今回のCVE-2026-34219の発見は、その能力がネットワークのコアシステムソフトウェアやネットワーキングレイヤーに対して配備されたという点で、重要な転換点となる。
システムソフトウェアはより難易度の高い対象だ。コードは低レイヤーであり、攻撃対象領域にはリアルタイムのプロトコル状態が関与する。また、時間演算における整数オーバーフローのような脆弱性は、スマートコントラクトが提供する「トランザクションのロールバック（差し戻し）」のような安全網がないため、即座に深刻な結果をもたらす。クラッシュしたバリデータはロールバックせず、単にオフラインになる。
イーサリアム財団が2025年5月に発表した「Trillion Dollar Security（1兆ドル規模のセキュリティ）」イニシアチブは、イーサリアムが保護する資産価値の増大に伴い、ネットワーク全体の回復力を高める取り組みの一環として位置づけられている。2026年初頭時点で、イーサリアムはオンチェーンで6,000億ドル（約97兆2,000億円、1ドル=162円換算）以上の資産を保護しており、同イニシアチブは数兆ドル規模の資産を安全に扱えるようにすることを目標に掲げている。
悪用される前にCVE-2026-34219が公開されたことは、AI支援モデルのもとで「発見、検証、パッチ適用、協調的な公開」というセキュリティパイプラインが正しく機能し得ることを示している。しかし、そのパイプラインにおける人間の役割は変わっていない。
Baxevanis氏は「AIはセキュリティ研究者を置き換えたのではなく、業務を移行させたのだ」と記している。「かつて仮説を考案し、それを追跡することに費やされていた時間は、今やそれらを大規模に評価・判断することに費やされている。ボトルネックが解消されたわけではない。バグを見つけることから、結果を信頼することへと移行したのだ。人間の判断力が真に重要となる場所へ移行したという意味で、これはより良い変化である」
バグの発見は高速化したが、どのバグが本物であるかを見極めるには、依然として人間の力が必要とされている。
■注目ポイントQ&A
●誰がパッチを適用する必要があり、その緊急度はどの程度ですか？
Rust版のlibp2p-gossipsubを基盤とするコンセンサスクライアント、バリデータノード、インデクサー、またはアプリケーションを運用しているすべての管理者は、直ちにバージョン0.49.4以降へアップグレードする必要があります。この脆弱性は通常の接続以外の認証情報を必要としないため、ネットワーク上の任意のピアからクラッシュを誘発される恐れがあります。また、再起動後も繰り返し攻撃が可能であるため、パッチ未適用のノードは攻撃者に対して無防備な状態になります。この影響はイーサリアムのインフラだけでなく、該当するRustクレートを使用しているすべての本番アプリケーションに及びます。
●従来のファズテスト（ファジング）によるバグ発見と何が違うのですか？
ファザー（fuzzer）が最大値に近いバックオフ値を持つPRUNEメッセージを生成した場合、クラッシュログとスタックトレースが返され、人間のエンジニアは数分でクラッシュを確認できます。一方、AIエージェントの手法では、コードパスの解説、深刻度の根拠、概念実証（PoC）コードを含む、人間が読める形式のレポートが生成されます。違いは発見された内容そのものではなく、発見に付随する情報の形式にあります。AIは本物のバグに対しても誤検知に対しても、同じフォーマットと速度でもっともらしいレポートを作成するため、本番環境で実際に到達可能な脆弱性を見極める「トリアージ」の負担が人間にシフトすることになります。
●Rust言語を使用していれば、この種の攻撃を防ぐことはできないのですか？
部分的には防げますが、「Rustだから安全」という一般的なイメージとは異なります。Rustの整数オーバーフロー時の挙動（RFC 560）により、ランタイムは未定義の動作やメモリ破壊を起こさずにパニック（強制終了）します。これにより、今回の脆弱性がリモートコード実行やメモリ破壊に発展することは防げましたが、ノードがクラッシュしてオフラインになるという「サービス拒否（DoS）」の脆弱性としては残りました。メモリ安全性とクラッシュ安全性は異なる特性であり、任意のピアから制御メッセージを受け入れる設計である以上、入力値検証の不備があれば言語のメモリモデルに関わらず遠隔からのクラッシュを許すことになります。
●AIを用いたセキュリティ研究は、イーサリアムを新たな危険にさらすことになりませんか？
懸念はもっともですが、プロセスの順序が重要です。自社のコードに対してAIエージェントを実行すると詳細な脆弱性レポートが生成されますが、パッチ適用前にこれが漏洩すれば攻撃者のロードマップになってしまいます。イーサリアム財団は、手法を公開する前にv0.49.4へのパッチをリリースし、協調的な公開プロセスを完了させることでこれに対処しました。最大の懸念は、防御側が実行する前に攻撃者が同じAI手法をインフラに対して展開することであり、これこそが「Trillion Dollar Security」イニシアチブにおいて防御側が先手を打つべき理由となっています。
元記事: Ethereum Gossipsub Flaw Lets Any Peer Crash Validators: AI Found It, Humans Confirmed