EIP-7702はバイナンスの63億ドル窃盗事件の主因ではない。問題は署名の取得方法にある。

Tapbit Wire - Tapbit NewsTapbit Wire·出典:TheBlockBeats·
共有

北京時間2026年10月30日4時24分。

チェーン上記録によると、資金は0x28C6…1d60から流出。このアドレスは「バイナンス14」と呼ばれ、同社最大級のイーサリアムホットウォレットの一つで、毎日数千件の出金を処理。今回のトランザクションでは167,464 ETH、16.15億ドル相当のUSDT、および60種類以上のトークン(当時の総額約25億ドル)が移動。残高は1 ETHのみに。

ガス料金は0.0004 ETH(1ドル未満)。

3分前の4時21分、誰かがEIP-7702形式のトランザクションをこのアドレスへ送信。50件の承認(nonce 18,914,775~18,914,824)を含むもので、うち49件は無効、1件が有効(ヒット)。ヒットとは:この瞬間から、バイナンス14への呼び出しは、前日夜23時59分に攻撃者がデプロイした検証済みでない「スイーパー」コントラクト(1つのスイープ機能のみ)を実行することを意味する。

つまりバイナンス14はもはやウォレットではなく、他人のプログラムを内包するシェルと化した。

午前8時6分時点で、この委任はまだ有効だった。3時間45分経過しても、誰もそれを取り消さなかった。

なお、この委任の「取消し」には、同一の鍵による1回の署名で十分。その日の午前6時55分、バイナンスはまだこの鍵を使って、未スイープの分散トークンを自社ウォレットへ戻す転送を行っていた。

EIP-7702は攻撃の主因なのか?

EIP-7702の仕組みはこうだ:通常のEOAアドレスが、自身のアドレス・残高・秘密鍵を一切変更せずに、スマートコントラクトのコードを「借りる」ことを許可する。借り方は、このアドレスのコードフィールドに23バイト(0xef0100+コントラクトアドレス)を書き込むだけ。これら23バイトは実行可能コードではなくポインタであり、以降、このアドレスへの呼び出しは、ポインタ先のコードを、このアドレス自身のコンテキスト(address(this)や残高も不変)で実行する。

この仕様にはバグはない。ゼロデブ創設者・EIP-7702関与者のデレク・チャン氏は、事件当日「EIP-7702自体に脆弱性はなく、これをサポートするウォレット利用者は不安になる必要はない」と明言。さらに「攻撃者が7702を悪用するには、秘密鍵の完全な制御、またはバイナンスを騙して7702承認の署名をさせる、いずれかが必要」と付け加えた。

これは攻撃ツールとして使われた初の事例ではない。イーサリアムPectraアップグレード後、ウィンタームートが数週間で、メインネット上の7702委任の97%以上がほぼ同一の「スイーパー」コントラクトを指していたことを発見。研究によると、約366万件の承認トランザクションのうち約63%が悪意あるコントラクトに関連し、確認済み損失は230万ドル。ブロッケイドは2026年前半に4件の7702関連インシデントを検証、合計損失約108万ドルとし、年内に7桁規模の事件が発生すると予測。

結果は10桁規模で、彼らの予測より3桁も大きかった。

これにより、人類史上最大の56億ドル規模のバイナンスハッキング事件の原因がEIP-7702だとする見方が広がった。しかし、本当に7702の問題なのか?

署名の取得方法

さらに掘り下げる前に、一点明確にしておく必要がある:50件の承認=50件の署名。では、これらの50件の署名は一体どのように生成されたのか?

攻撃者が完全な秘密鍵を入手していたなら、なぜ50個のnonceを盲目的に試す必要があったのか?鍵が常にバイナンスの管理下にあったなら、なぜ12分間に11のウォレットが同時に被害に遭ったのか?いまだ説明はない。

メインスイープから24秒後、バイナンス16は、同一の受取アドレスへ28,005.6 ETH、5,570万米ドル相当のUSDT、2,590万米ドル相当のRLUSD、および84.5 WBTCを送金した。

12分以内に、他の10のバイナンスホットウォレットが、4つのブロックチェーン上で同様の送金を行った:オプティミズム上のバイナンス55が4,420万米ドル相当のOPを送金;アービトラム上の4つのウォレットが7,460万米ドル相当のARBと8,426 ETHを送金;アバランチ上の4つのウォレットが181万AVAXと841万米ドル相当のUSDTを送金。

これらのウォレットにはいずれもコードが含まれておらず、すべてのトランザクションは、ウォレット固有の秘密鍵で署名された通常の送金であり、日常的な出金の間に挟まれていた。

秘密鍵を保有する者は、ノンスを盲目的にスナイプする必要はない。eth_getTransactionCountの確認は1秒で済む。

50個の連続ノンスに対応する50件の承認を一度に作成する必要があるのは、別のタイプの人間である:署名を取得できるがウォレットのリアルタイム状態にアクセスできない者、あるいは事前に組み立てられた承認を一括で提出し、システムに試行させるしかない者。

特に注目すべきは、この50件の承認が単一のトランザクションで一度に承認されたことである。

セキュリティ企業Blockaidは、「鍵が不正使用された」と判断し、秘密鍵そのものが直接抜き取られたとは見なしていない。Yuga Labsのブロックチェーン担当VP Quit氏も同様の見解で、攻撃者が入手したのは「承認済み署名」であり、リレーヤー経由での提出は、署名の発信元を隠すためであった可能性がある。

沈宇氏が朝のまとめで指摘した詳細:06:55まで、バイナンスは依然として同一の秘密鍵で署名を行い、回収されなかったフラグメントトークンを自社ウォレットへ戻していた。

これは、当該朝時点で鍵がまだバイナンスの管理下にあったことを示している。

本日10:26、バイナンスは暫定報告を発表:DevOpsエンジニアのノートPCが侵害され、攻撃者がサービスコンテナにアクセスして不正な出金トランザクションを提出した可能性がある。現時点では、ウォレットの秘密鍵漏洩の証拠は確認されていない。

失われた瞬間は、オンチェーン上ではない。

したがって、核心的な問題はEIP-7702ではなく、署名前の段階にある。

ホットウォレットは1日に数千件のトランザクションを署名するため、自動化が必須である。同時にセキュアである必要があり、HSM、MPC、マルチシグ、承認フローなどの対策が必要となる。結果として、セキュリティモデル全体は一文に集約される:「このトランザクションを署名すべきでない」と、署名前に判断できるか?

問題は、ほとんどの判断基準が「金額」と「アドレス」の2項目しか持たないことにある。

EIP-7702の承認にはこれらがない。金額は存在せず、変更されるのは「いくら送金するか」ではなく「このアドレスが何であるか」である。

バイナンスが防御していなかったわけではない。

事件の3日前、10月27日に、バイナンスは注目に値する情報を自主開示:先週、セキュリティチームが北朝鮮関連の複数攻撃を検知・阻止した。その手法は「感染性インタビュー(Contagious Interview)」と呼ばれ、攻撃者は採用担当者を装い、面接やコーディングテスト、そして「まず開発ツールをインストールしてください」などと誘導して悪意あるプログラムを実行させ、実行後に鍵・内部ネットワーク・その後の資金移動への侵入口を確保する。

しかし、「このトランザクションを署名すべきか?」という判断は防げなかった。