ZetaChain のバグ：ホワイトハッカーが報告、当初は「想定内」と却下され、後に 33.4 万ドルの脆弱性を引き起こす
ZetaChain のバグ：ホワイトハッカーが報告、当初は「想定内」と却下され、後に 33.4 万ドルの脆弱性を引き起こす
2026 年 4 月下旬、クロスチェーンインフラストラクチャは、小さな設計上の仮定がどのようにして大きなリスクに発展するかを再び証明しました。ZetaChain は、メッセージの初期化、宛先チェーンの実行ルール、および長期間有効な ERC-20 承認にまたがる一連の弱点を介して、攻撃者がプロトコル管理ウォレットから約 33.4 万ドルを引き出したことを確認しました。ユーザー資金は影響を受けませんでしたが、このインシデントは依然として鋭い教訓となっています。クロスチェーンシステムでは、「低リスク」コンポーネントは、相互作用する際に、ほとんど低リスクに留まりません。
このケースが特に教訓的である理由は、技術的な失敗の背後にあるプロセス上の失敗です。ZetaChain は、コアとなる問題がバグバウンティチャンネルを通じて以前に報告されていたことを認めましたが、当初は対策やより厳格な制約を必要とするものとしてではなく、意図された動作として扱われました。開示とインシデント後の詳細については、Coindesk の報告書など、ZetaChain はエクスプロイトを防ぐ可能性があったバグ報告を却下したのような報道で確認できます。
以下は、運用担当者向けの、何が起こり、なぜエクスプロイトパスが機能し、ZetaChain は何を変更し、2026 年にビルダーとユーザーが何を学ぶべきか（クロスチェーンアクティビティがかつてないほど広がり、攻撃者のプレイブックがますます「デフォルトでマルチベクトル」になっている現在）についての内訳です。
インシデントスナップショット：クロスチェーン設計の負債が返済される
攻撃者の行動は最終的に、イーサリアム、アービトラム、ベース、BNB スマートチェーンにまたがる 9 件のトランザクションにつながりました。盗まれた資産は、エンドユーザーではなく、ZetaChain によって制御されるウォレットから供給されました。ZetaChain は、問題が封じ込められるにつれてクロスチェーン操作を一時停止しました。最初の停止は、インシデントが最初に公になった際に広く報道されました（参照：The Block の停止と緩和策に関するレポート）。
金額は「ブリッジ・メガハック」の規模ではありませんでしたが、パターンが重要です。プロトコル署名付きコールを外部チェーンで生成するように影響を与えることができるクロスチェーンゲートウェイは、たとえ直接的な被害者が限定的であっても、高レバレッジのターゲットとなります。
厄介な教訓：「想定される動作」でも悪用される可能性がある
バグバウンティプログラムは、敵対的な好奇心を防御的な改善に変換することを目的としていますが、トリアージが** composability risk（構成可能性リスク）**を認識できるように構築されている場合に限ります。
ZetaChain は以前、Immunefi との提携でバグバウンティプログラムを立ち上げました（背景：ZetaChain のバグバウンティ発表）。しかし、このインシデントは、業界で繰り返し発生する課題を浮き彫りにしています。報告書は、個々のコンポーネントが単独ではクリティカルではないように見えても、「正しい」場合があります。Immunefi 自体も、実際の影響と範囲の定義が重要であることを強調しています（参照：Immunefi のプログラムルールと影響に関するガイダンス）。
クロスチェーンプロトコルにおいては、基準はさらに高くなるべきです。「プロトコルが、意図しないものを署名するように騙される」可能性のあるパスが 1 つでもあれば、たとえその機能が技術的には設計どおりに機能していても、防御的な深さが必要です。
3 つの「小さな」問題が 1 つの大きなエクスプロイトに連鎖した方法
呼び出しフローとコントラクトの動作の詳細な技術的ウォークスルーは、独立した研究者によって公開されました。最も明確なステップバイステップ分析の 1 つは、ZetaChain Gateway hack analysis です。
セキュリティ設計の観点から、エクスプロイトチェーンは 3 つのリンクに要約できます。
1) ゲートウェイレイヤーでのパーミッションレスなクロスチェーン命令の開始
根本的な問題の 1 つは、ゲートウェイ側のパスが、システムがオリジネーションを許可されるべき対象に対する予想される信頼境界を強制することなく、攻撃者がクロスチェーンの意図（つまり、「このメッセージ/コールを宛先チェーンに送信する」）を注入できるように悪用されたことでした。
クロスチェーンシステムでは、「リモートで実行されるべき」シグナルを発行できるのは誰かが、最初の、そして最も重要な防御線です。
2) 制限が緩すぎた（そして狭い拒否リストに依存しすぎた）宛先実行ルール
受信側では、実行パスが実質的に「任意」の性質を持つ呼び出しを許可しており、危険なトークン操作をブロックするには制限が十分ではありませんでした。少数のセレクターのみをブロックするブラックリストは、EVM の表面積が広大である場合、そして攻撃者が収益化するために必要なのは transferFrom のような 1 つの許可されたプリミティブだけである場合、ほとんど十分ではありません。
これは一般的な障害モードです。拒否リストは、敵対的な環境ではすぐに陳腐化します。
3) 古い ERC-20 承認が「実行」を「資産移動」に変えた
最後のリンクは、純粋にコードではなく運用上の問題でした。一部のウォレットは、ゲートウェイコントラクトに対して 無制限の承認（またはその他の過剰な承認）を保持しており、もはや必要なくなった後もクリアされていませんでした。
ERC-20 では、承認は実質的に継続的な許可です。コントラクトがトークンコールを自分自身として行う能力を得ると、残りの承認はすべて装填された武器になります。標準レベルでの承認の仕組みについては、OpenZeppelin の ERC-20 ドキュメントを参照してください。
研究では、単一のプロトコルを超えて、無制限の承認がどの程度広範に普及しており、それらがなぜシステムリスクを生み出すのかも示されています（参照：「ペニーワイズ・ポンド・フーリッシュ」承認リスク調査）。
攻撃者の手口：機会主義的ではなく、計画的
ZetaChain は、このエクスプロイトを、以下を含む明確な計画の兆候を示していたと説明しました。
- 数日前の Tornado Cash による事前資金調達
- 専用の「ドレイナー」コントラクトのデプロイ
- アドレスポイゾニングキャンペーンの実行
アドレスポイゾニングは、小売詐欺としてだけでなく、インシデント対応中の混乱を招く方法としても、より広範なエクスプロイト操作にますます組み込まれているため、特別な注意が必要です。この手法の厳密な概要とその成功率の高さの理由を知りたい場合は、カーネギーメロン大学の研究者が専用のリソースをここに維持しています。ブロックチェーンアドレスポイゾニングの概要。
ZetaChain が変更したこと：バグの修正だけでなく、危険な機能を削除
インシデント後の修正は、観察されたペイロードを 1 つだけブロックするのではなく、クラスリスクを軽減する場合に最も重要です。ZetaChain が開示した修正の方向性（公開報道と技術分析で要約されている）に基づくと、主な変更点は次のとおりです。
- メインネットインフラストラクチャへのパッチの展開により、悪用されたパスを閉鎖。
- 「プロトコルが署名する任意の calldata を実行する」という結果を可能にした任意呼び出し機能を永久に無効化。
- デポジットフローの無制限承認パターンを、正確な金額承認に置き換え、単一の承認が数か月後にサイレントに有効なままにならないように。
最も重要なテーマは、「強力だが危険な汎用性」から「狭く、検証可能な意図」への移行です。2026 年に安全にスケールしたいクロスチェーンプロトコルは、ますます許可リスト登録されたターゲット、型指定されたメッセージ、および機能制限付き実行をデフォルトにする必要が出てくるでしょう。
ビルダー向けの教訓：2026 年のクロスチェーンセキュリティは、コンポーネントではなく構成にある
ZetaChain 以外でも、クロスチェーンシステムは、以下との交差点に位置しているため、攻撃され続けています。
- 複雑な状態マシン、
- 分散型署名/検証、
- そして非常に収益性の高いトークンインターフェイス。
業界の損失レポートは、エクスプロイトの深刻度が依然として高く、テールリスクイベントが結果を支配していることを示し続けています（集計された業界追跡の例としては、Immunefi の「2025 年第 1 四半期の仮想通貨損失」レポート (PDF) を参照）。
クロスチェーンメッセージングを設計または統合している場合は、次の実践的なガードレールを検討してください。
- メッセージのオリジネーションを明示的かつ認証されたものにする：「クロスチェーン呼び出しをリクエストできるのは誰でも」は、「プロトコルが署名して実行する」と同義であってはなりません。
- 実行シンクの拒否リストを避ける：許可リストと最小限のインターフェイスを優先する。
- 承認を脅威モデルの一部として扱う：財務室/運用担当者のウォレットには、厳格な承認ポリシー、監視、および定期的なクリーンアップが必要です。
- 緊急調整の計画を立てる：署名とクロスチェーン実行が関係する場合、SEAL 911 のようなインシデント対応ネットワークは、分単位が重要であるため存在します。
ユーザーチェックリスト：クロスチェーンインシデント後の対処法（「ユーザーは影響を受けなかった」場合でも）
プロトコルがユーザー資金に影響がなかったと述べている場合でも、特に影響を受けたゲートウェイコントラクトとやり取りしたことがある場合は、個人の影響範囲を縮小するために 10 分間を費やすのは合理的な行動です。
1) 不要な承認を取り消す
信頼できる 2 つのオプション：
- Revoke.cash トークン承認ガイドのような承認管理ツールを使用する
- または、ブロックエクスプローラーの組み込みチェッカー（Etherscan のトークン承認チェッカーなど）を使用する
2) 日常の行動におけるアドレスポイゾニングから身を守る
- トランザクション履歴から受取人をコピーしない。
- 可能な場合は、アドレス帳/信頼できる連絡先を使用する。
- 最初の数文字/最後の数文字だけでなく、検証する。ポイゾニング攻撃は、ウォレット UI が切り捨てるものと一致するように設計されています。
3) 高額な送金にはハードウェアベースのアドレス検証を使用する
ハードウェアウォレットは、制御していないプロトコルのスマートコントラクトバグを停止することはできません。しかし、アドレスポイゾニングやクリップボード操作のシナリオ中に、誤った受取人を個人的に承認する可能性を減らすことができます。
ここで OneKey は自然にフィットします。署名を分離し、オンデバイス検証を強調することで、「署名するもの」と「意図するもの」を近づけるのに役立ちます。特に、攻撃者が混乱を悪用しようとするストレスの多い状況では。
結びの言葉
ZetaChain のエクスプロイトは、現代の暗号セキュリティの現実のコンパクトなケーススタディです。
- 以前に報告された問題、
- 「設計どおり」という仮定により却下され、
- 許可された実行と残存する承認と組み合わされ、
- 事前に資金、ツール、ソーシャルレイヤーのノイズを準備していた攻撃者によって実行された。
2025〜2026 年が業界に何かを教えてくれたとすれば、それはクロスチェーンシステムが敵対的な構成のために設計されなければならないということです。最も安全な機能は、すべてが「予想どおりに動作している」場合でも、誤って署名オーラクルにできない機能です。
