Beosin Alertプラットフォームの監視データによると、2026年8月には、各種セキュリティイベントによる損失総額は約7615万ドルに上り、重大なセキュリティイベントは『29』件発生しました。主な原因はスマートコントラクトの脆弱性です。そのうち、スマートコントラクトまたはネットワークの脆弱性によるイベントは18件、秘密鍵の漏洩による損失は2件でした。スマートコントラクトのセキュリティと秘密鍵管理は、依然としてWeb3セキュリティにおける弱い環です。
8月の損失トップ10
8月13日，个人用户地址0x13e3....179e因私钥泄露被盗走WBTC、cbBTC、LDO、USDS、CRV等加密资产，总损失约2560万美元，是实际损失最多的安全事件。8月30日，Cronos 网络上的借贷协议 Tectonic 因合约漏洞遭遇黑客攻击，预计损失约为 7400 万。此次攻击导致Cronos网络采取紧急措施，暂停网络并回滚交易，黑客最终通过跨链交易，成功转移约600万美元到Ethereum网络。
また、Harmonyチェーンは脆弱性により約40億枚のONEトークンが追加で鋳造され、名目上の損失は400万ドル以上となったが、最終的にトランザクションをロールバックすることで偽造トークンの状態が削除されたため、損失には計上されていない。
攻撃されたプロジェクトの種類と各チェーンの損失状況
今月の攻撃対象は、パブリックチェーン、貸借プロトコル、ウォレットアプリ、トークン契約、クロスチェーンブリッジ、一般ユーザーなど多岐にわたり、その中でDeFiプロジェクトの損失額が最も高く、3309万ドルに達した。一方、個人アドレスは秘密鍵の漏洩やフィッシングにより約2840万ドルの損失を被った。トークン関連の契約が最も多く、10回の攻撃が確認された。DeFi関連の契約はその次に多く、合計9回の攻撃を受けた。
5月で損失額が最も多かったブロックチェーンはEthereumで、損失額は4858万ドルを超え、合計15件のセキュリティイベントが発生しました。現在、大多数のDeFiプロトコルおよびマーチャントを対象としたフィッシング攻撃は依然としてEthereumを主なターゲットとしています。セキュリティイベント発生件数が2番目に多いブロックチェーンはBNB Chainですが、攻撃の主な対象はトークン契約であり、損失額は比較的小さいです。また、Cronos、Base、Harmony、Bitcoin、Solanaなどのパブリックチェーンでもセキュリティイベントが発生しており、チェーン上の攻撃はマルチチェーン化しています。
主要なセキュリティイベントの分析
1. Tectonic と Moonwell：価格操作
TectonicとMoonwellはオンチェーン貸付プロトコルであり、両者とも流動性が低いトークンの担保価格が操作されたことが攻撃の原因となった。これにより、虚偽に高められた資産価値を基に過剰な資産を借り入れ、利益を獲得した。Tectonicの攻撃では、攻撃者がTectonicプロトコルのガバナンストークン$TONICの価格を100倍に引き上げ、約7,400万ドルの貸出枠を獲得し、その後USDTなどの資産を借り入れた。事件発生後、Cronosネットワークはチェーン全体のブロック生成を緊急停止し、攻撃者はネットワーク停止前に約600万ドルをイーサリアムへクロスチェーンで転送した。その後、Cronosネットワークはロールバックを実施し、損失の回復を図った。
ハッカーによるイーサリアムの利益アドレス：0xc404160B79BD8905061a1cAecBeCa2EEab3f72DD と盗難資金の流れ：
現在、約2659 ETHが0xc4041に保管されています。140.1 ETHが0x6df89c42f0abdfaa2b5b77edcdafbc945ed6ee6cに転送された後、複数の新規作成されたアドレスに分散して送信されています。
Moonwellは、攻撃者が流動性が不足しているMAMOトークンの価格を操作してcbBTCを貸し出し、約870万ドルの損失を被りました：
この2つの攻撃はスマートコントラクトの脆弱性に基づくものではなく、プロトコルが脆弱なスポット流動性から担保の価格を決定し、担保価値を誤って計算したことが原因です。このような攻撃を回避するためには、プロトコルが複数のオラクルから異なるソースのデータを取得し、価格の急激な変動に対して追加の判断を実施することが可能です。
2. Harmony：リプレイ攻撃
Harmonyは、4つのシャードを実行し、レシートに基づく非同期クロスシャードメカニズムを用いてそれらの間でアセットを転送するシャーディング対応のLayer 1です。送信元シャードは出力トランザクション用に暗号化レシートを生成し、受信先シャードは、そのレシートとMerkle証明が署名済み送信元ブロックヘッダーと一致していることを確認し、各レシートは一度だけ使用可能であることを保証します。
今回の攻撃の脆弱性は、Harmonyのシャードシステムのレガシー部分に存在します。以前、Harmonyは2つのフィールドCXMerkleProof.ShardIDとBlockNumを確認することで、シャードレシートが既に使用されているかをチェックしていました。
これらのフィールドは署名されたブロックヘッダーの外側に位置しているため、攻撃者は既存の機能を破壊することなくこれらを変更できます。今回の攻撃では、攻撃者がシャード間レシートを取得し、そのShardIDとBlockNumを変更して、検証プロセスがこれを新しいレシートと認識させるようにしました。ターゲットシャードは変更されたレシートを受け入れて再び記録しましたが、元のシャードは対応する資産を差し引いていません。
これは非常に典型的なリプレイ攻撃です。「一回限りのトークン」に使用されるフィールドは、すべて署名ヘッダーの認証部分に含まれている必要があります。レシートの検証時には、証明構造内の未認証フィールドを信頼するのではなく、認証済みのブロックヘッダーから直接シャードIDとブロック番号を読み取る必要があります。
3. Term Finance：ガバナンス攻撃
Term FinanceはDeFi固定金利貸付プロトコルであり、各ヴァルトはYearn V3コードに基づくERC-4626ヴァルトです。Term Financeのヴァルトガバナンスは承認投票ではなく、拒否投票です。キュレーターがパラメータ変更案を提案すると、ガバナーはLPトークン保有者が反対意見を提出するための窓口を開きます。しかし、ガバナンス投票の閾値設定には深刻な脆弱性があります：
● 絶対票数または資本の下限が欠如：提案が通過する条件であるisSupportThresholdReached()とisMinParticipationReached()は、絶対票数ではなく相対比率のみをチェックします。これは、相対的多数が満たされれば、投票した総人数や総資本量に関係なく提案が通過できることを意味します。
● 極めて低い参加率：ほぼすべての預金者が、投票に参加するために金庫シェア（tmvETH）をガバナンストークン（gtmvETH）にラップしていません。これにより、関連する金庫のガバナンストークンの総供給量が極めて低くなっています。
攻撃者は上記の設計上の欠陥を悪用し、極めて低いコストで金庫に対するガバナンス攻撃を実行しました：
(1) 投票権の取得：攻撃者は約0.5 ETHを用いて約0.485個のtmvETHファンドシェアを取得し、それを1:1で0.485個のgtmvETHガバナンストークンにラップして投票権を獲得した。
(2) 悪意プロポーザルの提出：攻撃者がプロポーザルを提出した際、契約は当時のガバナンストークンの総供給量を0.535 gtmvETHと記録しました。これは、攻撃者が保有する0.485 gtmvETHが総量の90.66%を占めていることを意味します。
(3) 投票と実行：攻撃者は唯一の投票者として賛成票を投じた。反対票が存在しないため、支持率は50%の閾値を大幅に上回り、同時に個人の投票権も、極めて低い総供給量に基づいて計算された最低参加要件（minVotingPower）を上回った。
(4) アセットの引き出し：提案が承認された後、悪意のある操作が実行され、金庫内のアセット（WETH）が引き出された
攻撃者は同じ手法を用いて、Term Financeの6つの金庫を攻撃し、約850万ドルの損失をもたらしました。
今回の攻撃は、チェーン上プロトコルガバナンス攻撃の非常に典型的な事例です。チェーン上ガバナンスにおいて、プロジェクト側は以下のチェックポイントを設定して予防すべきです：
● 絶対票数または資本下限の設定：ガバナンス提案は相対比率のみに依存して通過してはなりません。一定の金額（例：100万ドル）または独立アドレス数などの絶対数に基づくハードルを設定する必要があります。
● 時間ロックにガーディアンまたはキャンセルパスを設定：ガバナンス実行には通常遅延がありますが、これは一定の対応時間を確保するものです。プロジェクト側は、実行遅延期間中に有効なガーディアンメカニズムまたは提案キャンセルパスを設ける必要があります。遅延期間中に悪意のある提案が発見された場合、ガーディアンは即座に介入してキャンセルできます。
● ガバナンス参加の監視：プロトコルは、各トレジャーのガバナンス参加状況をリアルタイムで監視する仕組みを構築すべきです。あるトレジャーのガバナンストークンの総供給量や投票参加率が異常に低い場合、即座にアラートを発信し、必要に応じて保護措置を自動的にトリガーします。
Web3のセキュリティ脅威のトレンド
2026年におけるWeb3セキュリティが示す最も深いトレンドは、攻撃面の体系的な拡大である。脆弱性はコードレベル、日常的な運用、インタラクションの各段階で同時に発生しており、数回のセキュリティ監査やツールだけでは、運用セキュリティ、チェーン上ガバナンス、ビジネスロジックの脆弱性などに対応できない。これはWeb3プロジェクトがセキュリティ防御体制を構築する上で新たな課題を突きつけている。
また、DeFi契約および個人ユーザーに対する攻撃が頻発しています。契約の脆弱性や承認は攻撃者に容易に悪用される可能性があるため、契約の開発者や運営者は契約のセキュリティを再確認し、コア業務を処理する契約については複数回、複数の機関によるセキュリティ監査を実施すべきです。個人ユーザーは、ブロックチェアブラウザや承認取り消しツールを定期的に使用して、使用していない契約の承認を確認・取り消しし、一般的かつ新しく登場するフィッシング手法についてより深く理解することで、セキュリティ意識を高める必要があります。
本文はBeosinセキュリティチームがBeosin Alertセキュリティアラートシステム、チェーン上データ、プロジェクト側が公開した事後分析を基に作成しました。ご質問やフィードバックがございましたら、お気軽にお問い合わせください。