ロジック・検証の欠陥
全体の被害額の22%・8件
必要な検証が抜けている、初期化やアクセス制御を誤っている、といった実装ミス。ブリッジの署名検証・メッセージ検証の欠陥はここに含まれる。
典型的な流れ:「誰が」「何を証明したか」の確認が一箇所だけ欠けていて、そこから任意の引き出しやミントが通る。
2016年の The DAO から2026年まで、被害額が大きく、手口から学べることの多い39件を、攻撃の手口・根本原因・その後の経過で整理した。被害額の合計は約111億ドルになる。下のブロックは事件を古い順に並べたもので、面積が被害額、色が原因の大分類を表す。
最終更新:2026年10月
BLOCK #39 / 2026年10月29日 / 取引所・Ethereum
Binance33億ドル
鍵・署名プロセスの侵害:ホットウォレットの Binance 14 が EIP-7702 で攻撃者のコントラクトに委任され、1回のトランザクションで約25億ドル分の資産が引き出された。
攻撃の主戦場は、コントラクトのコードから、鍵を持つ人と署名の手順へ移ってきた。
2025盗まれた総額 約34億ドル、うち北朝鮮関連 約20.2億ドル(59%)1月から12月上旬まで。個人ウォレットの被害(約7.1億ドル)を含む。Bybit の1件で全体の約44%。
| 年 | 盗まれた総額 | 北朝鮮関連 | 割合 |
|---|---|---|---|
| 2021 | 32億ドル | 4億ドル | 13% |
| 2022 | 38億ドル | 17億ドル | 45% |
| 2023 | 17億ドル | 10億ドル | 59% |
| 2024 | 22億ドル | 13.4億ドル | 61% |
| 2025 | 34億ドル | 20.2億ドル | 59% |
2025年に盗まれた約34億ドルのうち、Bybit の1件だけで約15億ドル、全体の約44%を占めた。上位3件でサービスの被害額の69%になる。平均的な事件ではなく、最悪の事件に備える必要がある。
北朝鮮に関連する窃取額は2024年に13.4億ドル(全体の61%)、2025年には20.2億ドルと過去最高を更新した。2026年も Bitget の事件で10億ドルを超えた。偽の求人や取引先を装った接触から始まり、鍵と署名の手順を狙う。
2022年は盗難額の82%が DeFi で、その64%がブリッジだった。2024年には秘密鍵の侵害が盗難額の43.8%を占めて最大の要因になり、2025年の第1四半期は中央集権型のサービスが損失の88%を占めた。
TRM Labs によれば、2026年上半期のハッキングは207件と半年あたりの過去最多だった一方、被害額は約9.7億ドルにとどまった。その後、9月に Liquid Network(約3.2億ドル)と Bitget(約3.9億ドル)が続き、10月には Binance のホットウォレットから Bybit を超える規模の資産が流出した。
根本原因を7つに分け、それを「コードの欠陥」と「人と運用の欠陥」の2つにまとめた。件数ではコードの欠陥が多いが、2024年以降の被害額は大半が人と運用の欠陥による。
コントラクトやプロトコル設計そのものに穴がある。監査・テスト・形式検証で事前に見つけられる余地がある。
全体の被害額の22%・8件
必要な検証が抜けている、初期化やアクセス制御を誤っている、といった実装ミス。ブリッジの署名検証・メッセージ検証の欠陥はここに含まれる。
典型的な流れ:「誰が」「何を証明したか」の確認が一箇所だけ欠けていて、そこから任意の引き出しやミントが通る。
全体の被害額の2%・3件
外部呼び出しの最中に、状態を更新する前のコントラクトへもう一度入られる。The DAO 以来の古典だが、コンパイラのバグや読み取り専用の再入として形を変えて再発している。
典型的な流れ:送金・コールバックの後で残高を減らす実装で、同じ関数や同じ状態を参照する別の関数を再帰的に呼ばれる。
全体の被害額の4%・4件
丸め方向の誤り、精度の取りこぼし、オーバーフロー検査の誤りなど。集中流動性AMMやステーブルスワップのように固定小数点演算が多い設計で起きやすい。
典型的な流れ:1回あたりは微小な誤差を、境界値の状態をつくってから大量に繰り返し、価格や持分の計算を攻撃者に有利な方向へずらす。
全体の被害額の1%・2件
署名や鍵生成に使う乱数が弱い、署名の実装に偏りがある、といった暗号処理そのものの欠陥。鍵を盗まなくても、公開されている情報から鍵を割り出せてしまう。
典型的な流れ:予測できる乱数で作られた鍵や、偏りのある署名を、ブロックチェーン上の公開データから総当たりや統計分析で割り出す。
全体の被害額の5%・7件
コードは仕様どおりに動くが、価格オラクルや投票権といった経済的な前提が一時的に崩される。フラッシュローンによって、その資本コストはほぼゼロになった。
典型的な流れ:流動性の薄い市場で価格をつり上げ、その価格で評価された担保で借り入れる。あるいは借りた資金で議決権を得て、即座に提案を通す。
コードは仕様どおりに動いている。鍵を持つ人、署名に使う端末、配信されるUIが攻撃される。
全体の被害額の52%・11件
秘密鍵やマルチシグの署名者が、ソーシャルエンジニアリング・マルウェア・内部者によって奪われる、または騙されて悪意あるトランザクションに署名する。被害額ではここ数年の最大要因。
典型的な流れ:偽の採用面接や取引先を装って端末にマルウェアを入れ、署名画面に正常な取引を表示したまま、実際には権限移譲やコントラクトの差し替えに署名させる。
全体の被害額の15%・4件
コントラクトの外側、つまりWebフロントエンド、その配信基盤、DNS、依存ライブラリが改ざんされ、利用者に悪意ある承認や送金をさせる。
典型的な流れ:正規ドメインから配信されるJavaScriptに、特定のウォレットだけを狙って取引内容を書き換えるコードを差し込む。
各事件を開くと、手口の技術的な説明、根本原因、その後の経過、教訓、出典を確認できる。
39件中 39件を表示。被害額の合計は約111億ドル。
攻撃の流れを一歩ずつ追うと、どこで止められたかが見えてくる。手口の異なる4件を取り上げる。
2025年2月21日・Ethereum・約14.6億ドル・サプライチェーン・フロントエンド
2025年2月21日、Bybit の ETH コールドウォレットから約40万 ETH、約14.6億ドルが流出した。2026年10月の Binance の事件が起きるまで、単独の事件として暗号資産史上最大の被害だった。コントラクトにもハードウェアウォレットにもバグはなかった。攻撃者が侵入したのは Bybit ではなく、署名に使う Web アプリ Safe{Wallet} の配信基盤だった。
2月4日、Safe{Wallet} の開発者の macOS 端末が、Docker のプロジェクトを実行させるソーシャルエンジニアリングで侵害された。攻撃者は盗んだ AWS のセッショントークンで多要素認証を迂回し、翌日から Safe の AWS 環境に入り込んだ。
2月19日、S3 から配信される app.safe.global の JavaScript に、Bybit のウォレットからの取引のときだけ動き、署名の直前に取引の内容を差し替えるコードを注入した。他の利用者には何も起きないため、気づかれにくかった。
2月21日、Bybit の署名者はコールドウォレットからウォームウォレットへの定例の送金として、正規の URL の画面から Ledger で署名した。実際に署名されたのは、operation=1(delegatecall)で攻撃者のコントラクトを呼ぶ execTransaction だった。ハードウェアウォレットには、中身が読める形では表示されなかった。
delegatecall は、呼び出し先のコードを Safe 自身のストレージの上で実行する。攻撃者のコントラクトの transfer() は、ストレージのスロット0、つまりプロキシが参照する実装アドレス(masterCopy)を、攻撃者が用意したコントラクトに書き換えた。
新しい実装には sweepETH() と sweepERC20() があり、攻撃者は追加の署名なしで ETH、stETH、mETH などを引き出した。
実行の約2分後、S3 上の JavaScript は正規のものに戻された。
execTransaction(
to = 0x9622…7242, // 攻撃者のコントラクト
value = 0,
data = transfer(0xbDd0…9516, 0), // 新しい実装のアドレス
operation = 1, // delegatecall
...
)
// 攻撃者のコントラクトの transfer() は Safe のストレージ上で実行され、
// slot 0(masterCopy)を 0xbDd0…9516 に書き換える。
// 以後、Safe のプロキシは攻撃者の実装を呼ぶ。閾値3のマルチシグでも、全員が同じ UI を信じて署名すれば、そのUIが単一障害点になる。署名者が to と operation を別の環境でデコードしていれば delegatecall に気づけたし、Safe の Guard で delegatecall を拒否していれば、署名が揃っても実行は止まった。攻撃されたのは、最も頻度が低く、最も慎重に扱われているはずのコールドウォレットの操作だった。
2026年4月1日・Solana・約2.9億ドル・鍵・署名プロセスの侵害
2026年4月1日、Solana の無期限先物取引所 Drift から約2.85億ドルが流出した。攻撃者はコードの欠陥を一つも使っていない。約半年かけて関係者の信頼を得て、管理権限を移すトランザクションに署名させ、それを好きなときに実行した。
攻撃者はクオンツの取引会社を装い、約半年にわたって Drift の関係者と関係を築いた。
3月下旬、Security Council のメンバーに、無害に見えて実際には管理権限を移すトランザクションへ署名させた。Solana の durable nonce を使うと、署名済みのトランザクションは通常の約90秒で失効せず、いつでも実行できる。
3月26日、Drift はタイムロックのない 2-of-5 の Security Council に移行した。攻撃者は、この新しい体制の署名者からも署名を得ていた。
4月1日16時05分(UTC)、攻撃者は保持していた事前署名のトランザクション2つを1秒違いで実行し、管理権限を握った。
管理者として、自作の CarbonVote Token(CVT)を担保に登録し、自分が操作する価格で約1ドルに見せかけた。5億 CVT を預け、約2.5時間で JLP、USDC、cbBTC など18種類以上の実資産を引き出して Ethereum へ移した。
どの一歩も、コントラクトは仕様どおりに動いている。止められた地点は3つあった。署名者が中身をデコードして権限の移譲だと気づくこと、durable nonce を使った事前署名を監視すること、権限の変更にタイムロックを置くこと。最後の一つがあれば、管理権限が移る前に気づく時間があった。
2023年3月13日・Ethereum・約2億ドル・ロジック・検証の欠陥
2023年3月13日、レンディングプロトコルの Euler から約1.97億ドルが流出した。原因は、担保だけを減らせる関数に健全性チェックがなかったこと。何度も監査を受けたコードに、後から加えた一つの関数が穴を開けた。
Aave から 3,000万 DAI を借り、2,000万 DAI を Euler に預けて eDAI(担保)を得る。
mint() で約1.96億 eDAI と2億 dDAI(負債)を同時に作り、1,000万 DAI を返済してから、もう一度 mint() する。
donateToReserves() で1億 eDAI を準備金に寄付する。担保だけが減って負債はそのままなので、口座は大きな債務超過になる。この関数は、寄付の後に checkLiquidity() を呼んでいなかった。
別のアドレスから、この債務超過の口座を清算する。Euler の清算は債務超過が深いほど割引が大きく(最大20%)、清算する側は担保を割安に引き取り、負債の一部だけを引き継ぐ。
清算した側の口座に残った担保を引き出してフラッシュローンを返し、差額が利益になる。同じ手順を WBTC、stETH、USDC の市場でも繰り返した。
function donateToReserves(uint subAccountId, uint amount) external nonReentrant {
address account = getSubAccount(msg.sender, subAccountId);
// 担保(eToken)だけを減らし、準備金に移す
users[account].balance -= amount;
reserveBalance += amount;
// ここで checkLiquidity(account) を呼んでいない
}
function withdraw(uint subAccountId, uint amount) external nonReentrant {
address account = getSubAccount(msg.sender, subAccountId);
users[account].balance -= amount;
...
checkLiquidity(account); // 他の関数は最後に健全性を確かめる
}donateToReserves() は2022年7月のアップグレード(eIP-14)で追加された。問題は追加された関数そのものより、既存の清算ロジックとの組み合わせにあった。「残高が変わったら必ず健全性を確かめる」という不変条件を、関数ごとではなくプロトコル全体のテストとして書いていれば、ファジングで見つかる種類のバグだった。Euler は交渉で全額を取り戻したが、これは例外的な結末である。
2025年5月22日・Sui・約2.2億ドル・数値精度・オーバーフロー
2025年5月22日、Sui 上の DEX Cetus から約2.23億ドルが流出した。原因は Cetus 自身のコードではなく、依存していた数学ライブラリのオーバーフロー検査の条件式だった。
攻撃者はフラッシュスワップで資金を借り、プールの価格を大きく動かす。
tick の範囲 [300000, 300200] という極端に狭い価格帯を指定し、巨大な流動性でポジションを開こうとする。
必要なトークン量を計算する途中で checked_shlw(n) が呼ばれる。n は 2^192 を超えていて、64ビット左シフトすると桁があふれるが、誤った条件式はこれを安全と判定した。Move の左シフトは abort せず上位ビットを切り捨てるので、必要な量は1単位にまで小さくなった。
1単位のトークンで発行された巨大な流動性を引き出してプールの資産を抜き取り、フラッシュスワップを返済する。これを複数のプールで繰り返した。
Sui のバリデータが対応し、約1.62億ドルを凍結した。資金の回収は、その後のオンチェーン投票で承認された。
public fun checked_shlw(n: u256): (u256, bool) {
let mask = 0xffffffffffffffff << 192;
if (n > mask) { // 本来は n >= 1 << 192 を拒否すべき
(0, true) // オーバーフロー
} else {
((n << 64), false) // 2^192 以上の値もここに来て、上位ビットが失われる
}
}「checked」と名の付くヘルパーは、呼ぶ側が安全だと信じてしまう。問題の関数はプロトコル本体の外の依存ライブラリにあり、監査の範囲から外れやすかった。2^192 の前後の値を一つテストするだけで見つかるバグで、算術ライブラリこそ形式検証の対象にすべきだった。バリデータによる凍結は被害を抑えた一方で、チェーンがアプリの資金を止められることの是非も問うた。
対策を層ごとに整理し、どの攻撃手法に効くかを対応表にした。監査やファジングのようなコード側の対策は、人と運用の欠陥にはほとんど効かない。逆に、監視・出金制限・対応計画は原因を問わず被害を小さくする。どちらか片方では足りない。
| 対策 | ロジック | 再入 | 数値精度 | 暗号実装 | 価格操作 | 鍵・署名 | サプライチェーン |
|---|---|---|---|---|---|---|---|
| 実装 | |||||||
| 外部呼び出しの前に状態を確定させる | 主な予防策 | ||||||
| 状態を変える全経路の最後で健全性を検査する | 主な予防策 | 部分的に効く・被害を抑える | |||||
| 丸め方向をプロトコル有利に統一する | 主な予防策 | ||||||
| 初期化・権限まわりを手順ごとテストする | 主な予防策 | ||||||
| 鍵生成と署名は検証済みの標準実装に任せる | 主な予防策 | ||||||
| 検証 | |||||||
| 不変条件ファジングと形式検証 | 主な予防策 | 部分的に効く・被害を抑える | 主な予防策 | 部分的に効く・被害を抑える | 部分的に効く・被害を抑える | ||
| 監査とバグバウンティを継続する | 部分的に効く・被害を抑える | 部分的に効く・被害を抑える | 部分的に効く・被害を抑える | 部分的に効く・被害を抑える | 部分的に効く・被害を抑える | ||
| コンパイラと依存のバージョンを固定し、既知バグを追う | 部分的に効く・被害を抑える | 部分的に効く・被害を抑える | |||||
| 経済設計 | |||||||
| 操作されにくい価格源を使う | 主な予防策 | ||||||
| 流動性の薄い資産に上限をかける | 主な予防策 | ||||||
| ガバナンスに時間差を入れる | 主な予防策 | ||||||
| 鍵・署名・配信経路 | |||||||
| 署名者を組織・端末・場所で分散する | 主な予防策 | ||||||
| 署名する中身を独立に検証する | 主な予防策 | 主な予防策 | |||||
| 危険な操作をコントラクト側で拒否する | 主な予防策 | 部分的に効く・被害を抑える | |||||
| 採用・取引先を装う接触を前提にする | 主な予防策 | ||||||
| 委託先と外部サービスを信頼の境界の外に置く | 主な予防策 | 主な予防策 | |||||
| フロントエンドの配信経路を守る | 主な予防策 | ||||||
| 監視と対応 | |||||||
| 異常な資金移動を監視し、自動で止める | 部分的に効く・被害を抑える | 部分的に効く・被害を抑える | 部分的に効く・被害を抑える | 部分的に効く・被害を抑える | 部分的に効く・被害を抑える | 部分的に効く・被害を抑える | 部分的に効く・被害を抑える |
| 出金にレート制限と遅延をかける | 部分的に効く・被害を抑える | 部分的に効く・被害を抑える | 部分的に効く・被害を抑える | 部分的に効く・被害を抑える | 部分的に効く・被害を抑える | 部分的に効く・被害を抑える | 部分的に効く・被害を抑える |
| インシデント対応を平時に決めておく | 部分的に効く・被害を抑える | 部分的に効く・被害を抑える | 部分的に効く・被害を抑える | 部分的に効く・被害を抑える | 部分的に効く・被害を抑える | 部分的に効く・被害を抑える | 部分的に効く・被害を抑える |
● 主な予防策 ○ 部分的に効く・被害を抑える
Checks-Effects-Interactions を徹底し、共有状態を持つ関数群はまとめて再入ガードで守る。transient storage(EIP-1153)を使えば安価にコントラクト全体のロックをかけられる。再入中の不整合な状態を view 関数が返してしまう read-only reentrancy にも注意する。
関連する事件:The DAO、Curve(Vyper)、GMX V1
借入・寄付・清算・移転など、ポジションを動かす関数すべての終わりで担保比率などの不変条件を確認する。後から関数を足したときに検査が抜けるのが典型的な失敗。
関連する事件:Euler Finance
受け取る側の計算は切り上げ、渡す側の計算は切り捨てに揃える。外部の数値演算ライブラリも信用せず、オーバーフロー検査やビットシフトの境界値を自分でテストする。
関連する事件:KyberSwap Elastic、Cetus、Balancer V2
デプロイとアップグレードをスクリプト化してフォーク環境で再現し、0x00 や address(0) が「有効な値」として通らないか確かめる。任意の calldata を転送する関数や、検証者セットを書き換えられる関数は呼び出し元を限定する。
関連する事件:Nomad Bridge、Parity マルチシグ(盗難)、Parity マルチシグ(凍結)、Poly Network
署名のナンスは RFC 6979 などの決定論的な方式や標準ライブラリに任せ、独自に改変しない。鍵生成の乱数源はビルド設定まで含めて第三者に監査させ、出荷前に生成した鍵のエントロピーを統計的に検査する。
Foundry の invariant test や Echidna・Medusa で、「総負債は総担保を超えない」といった性質をランダムな操作列に対して検査する。数値演算ライブラリや署名・証明の検証ロジックは Certora や Halmos で形式検証する。
関連する事件:Euler Finance、KyberSwap Elastic、Cetus、Balancer V2、Wormhole、Liquid Network
監査はある時点のスナップショットでしかない。コードを変えるたびの再監査、競争型監査、被害想定額に見合った報奨金のバグバウンティを組み合わせる。Euler も Nomad も監査済みだった。GMX と Liquid Network では、以前の不具合を直す修正そのものが新しい脆弱性を持ち込んだ。資産が残る古いコントラクトも対象から外さない。
関連する事件:Euler Finance、Nomad Bridge、GMX V1、Liquid Network、Truebit
コンパイラとライブラリのバージョンを固定し、既知バグの告知が出たら自分のデプロイ済みコントラクトと突き合わせる。Curve の事件では、ソースコードは正しくてもコンパイラが再入ロックを壊していた。
関連する事件:Curve(Vyper)
単一プールのスポット価格を担保評価に使わない。TWAP や外部オラクルなど複数の価格源を組み合わせ、ソース間の乖離が大きいときは処理を止める。
担保として受け入れる資産ごとに、市場の厚みに応じた担保掛け目・供給上限・借入上限を設定する。価格を動かせても、その価格で借りられる額が小さければ攻撃は割に合わない。
関連する事件:Mango Markets、Cream Finance、Tectonic
投票権は提案前のスナップショットで数え、可決から実行までタイムロックを置く。即時実行の緊急手続きは、同じブロック内で借りたトークンで発動できないようにする。定足数は実際の投票率に合わせ、提案に含まれる命令はデコードして投票者に見せる。
マルチシグの閾値は、単一の組織や個人が過半を握らない構成にする。一時的に委任した署名権限やAPIキーは期限を決めて回収する。MPC や HSM も、運用が一人や一社に集中すれば同じ弱点を持つ。ブリッジの検証者も同じで、KelpDAO は単一の検証者とそのノードに依存していた。
関連する事件:Ronin Bridge、Harmony Horizon Bridge、Multichain、Orbit Bridge、KelpDAO
署名前に、ウォレットUIとは別の環境でトランザクションをデコード・シミュレーションし、Safe の tx hash をハードウェアウォレットの表示と照合する。operation が delegatecall になっていないか、宛先が想定どおりかを確認する。
関連する事件:Bybit、Radiant Capital、WazirX、Drift
Safe の Guard やポリシーエンジンで、delegatecall、owner や実装アドレスの変更、許可リスト外への送金を拒否する。権限の変更と高額の移動にはタイムロックをかける。人が騙されても、コントラクトが止める。
関連する事件:Bybit、WazirX、Radiant Capital、Drift
北朝鮮系のグループは、偽の求人、採用試験のコード課題、取引先を装ったファイル共有でエンジニアの端末に入り込む。署名権限や本番環境の権限を持つ人ほど、外部のファイルを開く端末と業務端末を分ける。
ウォレット事業者、カストディ、ステーキングAPI、署名UIなど、外部から受け取ったトランザクションや出金指示をそのまま署名・実行しない。宛先・金額・命令の種類を自社の側で独立に検証し、許可リストと上限を適用する。DMM Bitcoin、WazirX、Bybit、SwissBorg、Bitget は、いずれも委託先や外部製品が入口だった。
関連する事件:DMM Bitcoin、WazirX、Bybit、SwissBorg、Bitget
デプロイ権限を多要素認証と最小権限で絞り、配信中のJavaScriptが署名済みのビルド成果物と一致するかを監視する。SRI、CSP、DNS・レジストラのロックも入れる。資産を動かせるページには、計測や解析の外部スクリプトを読み込まない。Polymarket では、改ざんされたパフォーマンス計測のスクリプトが、ログイン中の利用者のセッションで取引を実行した。
関連する事件:BadgerDAO、Bybit、Polymarket
大口出金、権限変更、価格の急変を常時監視し、検知したら pause guardian が即座に停止できるようにする。自社の EOA に EIP-7702 の委任が設定されることも、権限変更として扱う。Ronin は流出に6日間気づかなかった。
関連する事件:Ronin Bridge、Nomad Bridge、KelpDAO、Cetus、Binance
一定時間あたりの流出量に上限を設け、大口の引き出しは遅延させる。原因の種類を問わず、被害の上限を前もって決められる数少ない手段。Liquid Network では、約4,000 BTC の払い出しが人の確認なしに通った。EOA のホットウォレットには上限をかけられないので、置いておく残高そのものが被害の上限になる。Binance 14 からは、1回のトランザクションで約25億ドル分が移された。
関連する事件:Nomad Bridge、Ronin Bridge、Wormhole、BNB Bridge、Liquid Network、Binance
停止権限を持つ人、連絡先(SEAL 911、取引所、ステーブルコイン発行体、チェーンのバリデータ)、ホワイトハットとの交渉方針(Safe Harbor 協定、報奨金の上限)を事前に決めておく。資金の凍結や返還交渉は最初の数時間で決まる。
関連する事件:Euler Finance、Cetus、KelpDAO、Bybit、Binance
被害額は事件発生時点の米ドル換算で、出典によって差があるものは代表的な値を採り、各事件の注記に幅を記した。攻撃者が後に返還した額や、凍結された額も被害額に含めている。日付は UTC。
掲載した事件は網羅的なリストではなく、被害額と手口から学べることの大きさで選んだ。個人が被害者の事件と、原因が公表されていない事件は除いている。ただし2026年10月の Binance の事件は、手口の大部分をオンチェーンで確認できるため、Binance の調査結果が公表される前だが暫定的に掲載した。攻撃者の特定は、捜査機関やセキュリティ企業の発表にもとづく。
年次の統計は以下の資料による。Chainalysis は過去の年の値を後の報告で修正することがあり、グラフには各年の報告の初出値を使った。各事件の出典は事件ファイルに記した。