Verus Ethereumブリッジ不正利用：繰り返される同一の1,158万ドルのバグ
2026年5月18日、何者かがVerus-Ethereumブリッジから1,158万ドルを流出させた。CoinDesk の報道によれば、今年8件目のブリッジハックだった。Verus Ethereumブリッジのエクスプロイトは、奇抜な新種の攻撃手法を用いたものではなかった。2021年からブリッジを次々と破壊してきた、あの同じ失敗の繰り返しだ。一方のチェーン上で実際に何が起きたかを正確に検証することなく、コントラクトが資金を放出してしまうという問題である。
脆弱な関数には今回、名前があった。checkCCEValuesだ。これは、Ethereum側でミントまたは解放を行う前に、クロスチェーンのエクスポート値が実態と一致しているかを確認するはずのルーチンだった。しかしその役割を果たせず、攻撃者は資金を持ち去った。
私は規制された環境でブリッジに隣接するインフラを4年間構築してきたが、落胆させられるのは、これがいかに予測可能な事態かという点だ。私たちは同じ傷に名前を付け替え続けている。
Verus Ethereumブリッジのエクスプロイトはソース検証の失敗だった
ブランドを取り除けば、あらゆるブリッジは一つのことをしているに過ぎない。チェーンA上のイベント（デポジット、ロック、エクスポート）を観測し、チェーンB上で対応するアクション（ミント、アンロック、リリース）を生成する。セキュリティモデル全体は、ただ一つの問いに収束する。チェーンBはチェーンAが伝えたことを本当に信じているか、そして検証したか。
ソース側の金額を確認する検証が誤っていれば、答えは「ノー」になる。攻撃者は主張するエクスポート値を偽造または水増しし、送金先のコントラクトはそれを信頼し、裏付けのないトークンがミントまたは解放される。The Block の報道によれば、損失はおよそ1,158万ドルで、クロスチェーンエクスポートチェックにおけるこうした会計上の欠陥を通じて流出した。
これがブリッジにおけるソース金額の検証であり、システム全体で最も重要な機能だ。一つの比較を誤れば、ブリッジはフリーマネープリンターと化す。
checkCCEValues は古い脆弱性の最新の名称に過ぎない
checkCCEValuesの脆弱性は、すでに業界に数十億ドルのコストをもたらしたバグと構造的に同一だ。名前は変わる。メカニズムは変わらない。
- Wormhole、2022年：署名検証のギャップにより、攻撃者はデポジットされていない120,000枚のWrapped ETHをミントできた。
- Nomad、2022年：merkleルートの初期化ミスにより、あらゆるメッセージがtrueと検証され、ブリッジはコピー&ペーストで大量に攻撃された。
- Multichain、2023年：外部から実際には検証できない鍵と信頼の前提。
これらはいずれも、本質的には、送金先チェーンがソースイベントの健全な証明なしに価値を解放したことだ。checkCCEValuesは、同じ言葉の2026年版の綴りに過ぎない。
業界はこれらを個別のエンジニアリングミスとして扱い続けているが、実際にはカテゴリーの失敗だと思う。一つの関数をより厳しく監査しても、カテゴリーの問題は解決できない。
Tornado Cash が攻撃者に資金を提供したことが、意図を物語る
攻撃者のウォレットは、エクスプロイト前にTornado Cashを通じて資金調達されていた。この詳細は、帰属の特定という点よりも、準備について何を示唆するかという点で重要だ。これは、結果に驚いたホワイトハットがコントラクトを触っていたものではない。Tornado Cash資金調達済みの攻撃者というパターンは、数日前に運用上のカバーを設定し、資金が外部に出る際にロンダリングが必要になることを見越していた人物の署名だ。
これが防御側が過小評価している点だ。エクスプロイトのトランザクションが着地した時点で、出口ルートはすでに構築済みだ。事後の追跡は検察官の役に立つが、8桁の損失を被ったプロトコルにはほとんど何の助けにもならない。
ブリッジのセキュリティ失敗は今や月次のコストとなっている
引いて見れば、Verusハックは外れ値ではなく、一行のコストだ。PeckShieldのデータをBitcoin.comが引用したところによれば、クリプトブリッジのエクスプロイトは2026年5月だけで約3億2,800万ドルに上った。今年5ヶ月も経たないうちに8件のブリッジインシデントだ。
市場はこれをクロスチェーンビジネスのコストとして静かに織り込んでいる。それは間違った教訓だ。定期的に9桁規模の月次損失が発生することはボラティリティではなく、設計空間が直視することを拒んでいる構造的欠陥だ。
実際の価値を動かすすべての人にとって、教訓は不快なものだ。ほとんどのブリッジは、数学の衣を纏った信頼の前提に過ぎない。私はかつて ステーブルコインブリッジが実際にどのように失敗するか で、最も安全なブリッジはしばしば、実際に何を検証しているかを率直に認めているものだと主張した。
本当に防御可能なブリッジチェックはどうあるべきか
ブリッジを構築または監査するなら、ソース金額の検証に対して不釣り合いなほどの注意を払うべき箇所がある。私が交渉の余地なしと考えることをいくつか挙げる：
- 送金先コントラクトは、リレーヤーの言葉ではなく、ソースイベントの暗号学的証明を検証しなければならない。レイテンシの予算が許す限り、マルチシグの証明よりもライトクライアントまたはzkプルーフを優先する。
- 金額チェックはすべてのパスで網羅的でなければならない。
checkCCEValuesクラスのバグは通常、一部の入力がスキップするブランチに潜む。比較をファジングし、目視確認だけに頼らない。 - 資産ごとのレート制限とサーキットブレーカーを設けることで、偽造された値が一つのトランザクションでリザーブ全体を枯渇させることを防ぐ。例えば、1時間あたりTVLの5%で自動停止するキャップがあれば、2026年のほとんどのインシデントの被害を抑えられただろう。
- ミント総量とロック総量をリアルタイムで監視し、乖離が生じた際に停止する独立した不変条件のモニタリング。
これらはいずれも新しいものではない。これらを捉えるための監査スタックは存在しており、私は監査スタックについての記事でそれを掘り下げた。問題は、ブリッジが検証を製品の核ではなく後付けとして実装し続けていることだ。
2026年の次のブリッジハックはすでに書かれつつある。関数名は異なり、根本原因は同じで、私たちはまた驚いたふりをするだろう。そうすべきではない。