週次Web3セキュリティインシデントまとめ｜2026年4月13日～4月19日

先週（2026/04/13 - 2026/04/19）、BlockSecは4件の攻撃インシデントを検出・分析し、推定総損失額は約**$310M**に上りました。以下の表はこれらのインシデントをまとめたものであり、各ケースの詳細な分析は後続のサブセクションに記載されています。

今週のハイライト：KelpDAO

エクスプロイト後のカスケード、Arbitrumのオンチェーン復旧メカニズム、およびガバナンスへの広範な影響を扱った専用レポートについては、以下を参照してください：分散化のジレンマ：KelpDAOクライシスにおけるカスケードリスクと緊急権限

このインシデントは、その新規性のあるインフラレベルの攻撃ベクトル（スマートコントラクトのエクスプロイトではなく、唯一のDVNを標的としたRCCポイズニング）、DeFiのコンポーザビリティを介した複数チェーンへのカスケード的影響、そしてArbitrumが盗まれた資金を回収するために強制的な状態遷移を行ったことにより提起されたガバナンス上の問題から、特に注目すべきインシデントとして取り上げています。

2026年4月18日、KelpDAOのrsETH LayerZero OFTブリッジが、国家支援アクター（おそらくDPRKのLazarus Group）によるとされる攻撃により、約$290Mに及ぶエクスプロイトを受けました [1]。根本原因はKelpDAOの1-of-1 DVN構成であり、これによりクロスチェーンメッセージ検証が単一障害点に集中していました。攻撃者はLayerZero Labs DVNが信頼するRPCインフラをポイズニングし、偽造されたクロスチェーンメッセージを証明させることで、Unichainでの対応するソース側イベントが存在しないにもかかわらず、Ethereum上で116,500のrsETHをリリースさせました。

背景

LayerZeroは、モジュラーセキュリティアーキテクチャ上に構築されたクロスチェーンメッセージングプロトコルです。その核心において、クロスチェーンメッセージの整合性は、分散型検証者ネットワーク（DVN）によって強制されます。DVNとは、送信先チェーンで実行される前に、ソースチェーンで送信されたメッセージが実際に発生したことを独立して検証する責任を持つオフチェーンエンティティです。LayerZero上でデプロイする各アプリケーションは、どのDVNを信頼するか、いくつ必要か、満たすべきコンセンサス閾値を含む独自のDVN設定を行います。このモジュール性によりアプリケーションはセキュリティモデルを完全に制御できますが、その責任も完全に負うことになります：脆弱な設定をプロトコル自体が補完することはできません。

KelpDAOのrsETHはLayerZero上でOFT（Omnichain Fungible Token）としてデプロイされており、Unichain（ソース）とEthereumメインネット（宛先）を接続するブリッジルートがあります。OFT標準では、ソースチェーンでトークンをバーンし、宛先チェーンのロックからリリースすることが可能であり、クロスチェーンメッセージがリリースの唯一の承認手段となります。Ethereum側のアダプター（0x85d456...e98ef3）は、有効なクロスチェーンメッセージが検証・配信された後に、受信者へrsETHをリリースする責任を担います。重要なのは、KelpDAOがこのパスウェイをLayerZero Labsを唯一の検証者に指定した1-of-1 DVN設定で構成したことです。これにより、単一のDVN証明だけでいかなるトークンリリースも承認するのに十分となり、第二の意見は不要となりました。

検証業務を行うにあたり、LayerZero Labs DVNは複数のRPCノードに対して、クロスチェーン送信イベントがソースチェーンで実際に発生したかどうかを確認するクエリを送ります。これらのRPCノードには自己運営のインフラと外部プロバイダーの両方が含まれており、DVNは証明に署名する前にそれらの集合的な応答に依存します。このプロセスの整合性は、クエリを受けたノードの過半数が真実のデータを返すという前提に依存しています。

脆弱性分析

この脆弱性は、インフラとコンフィギュレーションレベルにおける複合的な3つの欠陥で構成された組織的な障害です。

第一に、KelpDAOの1-of-1 DVN設定は、検証レイヤーにおけるすべての冗長性を排除しました。LayerZeroの推奨セキュリティ姿勢は、独立した検証者による複数DVN設定を明示的に要求しており、単一のDVNが一方的にメッセージを承認できないようにしています。LayerZero Labs DVNのみに依存することで、KelpDAOはその単一検証者への侵害が任意のトークンリリースを承認するのに十分となる状況を生み出しました。

第二に、DVNのフェイルオーバーメカニズムは、到達可能な残りのRPCノードに検証クエリをルーティングします。この設計はノードの不可用性が故意ではなく偶発的なものだと想定しています。しかし、これにより攻撃者はすべてのデータソースを侵害する必要がなくなります：DDoSによって正常なノードをオフラインにし、到達可能な唯一の代替として汚染されたノードを用意することで、DVNが受け取るデータを完全に制御できます。

第三に、RPCノード上のop-geth実行ファイルを置き換えるには、基盤となるサーバーへのOSレベルのアクセスが必要でした。初期アクセスベクトルの詳細は開示されていませんが、別々のクラスター上の2つの独立したノードを侵害したことは、これらのサーバーへのアクセス管理における共通の弱点を示している可能性があります。

これらの3つの条件が合わさることで、完全な攻撃チェーンが形成されました：第一の条件により証明されたメッセージをクロスチェックする独立したDVNが存在しなくなり、第二の条件により攻撃者は唯一のDVNが受け取るデータを完全に制御でき、第三の条件によりデータ操作を可能にする初期足がかりが提供されました。単一の弱点だけでは十分ではなかったでしょう。1-of-1設定がなければ、独立したインフラに問い合わせる第二のDVNが偽造メッセージを拒否していたでしょう。フェイルオーバーの挙動がなければ、正常なノードが汚染されたノードを多数決で否決していたでしょう。サーバーへの侵害がなければ、攻撃者は偽造データを挿入する手段を持たなかったでしょう。

攻撃分析

以下の分析は、トランザクション 0x1ae232...4222 およびLayerZero Labsによる公式インシデント声明に基づいています。

• ステップ1：攻撃者はLayerZero Labs DVNが信頼する特定のRPCノードのリストを入手しました。このリストは高価値の諜報ターゲットであり、正確なノードを知ることで広範なインフラ攻撃ではなく外科的な作戦の計画が可能になりました。

• ステップ2：攻撃者はRPCノードのうち2つにOSレベルの書き込みアクセスを取得し、実行中のop-gethバイナリを悪意のあるバージョンに置き換えました。これら2つのノードは互いに直接接続のない独立したクラスター上で動作していたとされており、初期アクセスベクトルが共有の上流依存関係（例：侵害されたデプロイ認証情報、CI/CDパイプライン、または両方へのアクセスを持つオペレーターへのソーシャルエンジニアリング）を含んでいたことを示唆しています。正確な初期アクセス方法はLayerZero Labsによって開示されていません。このステップはその後のすべてのデータ操作の前提条件でした。

• ステップ3：悪意のあるop-gethバイナリは標的を絞ったレスポンスロジックを実装していました：DVNのIPアドレスに対してのみ偽造されたトランザクションデータを返す一方、ブロックエクスプローラーやスキャンサービスを含む他のすべてのリクエスターには真実のブロックチェーン状態を提供しました。この選択的ポイズニングにより、既存のすべての可観測システムから攻撃は見えなくなりました；あらゆる外部の視点からは、ソースチェーンは正常に見えました。

• ステップ4：DVNの内部コンセンサスには、汚染されたRPCノードと侵害されていないRPCノードの両方における合意が必要でした。この矛盾を解決するために、攻撃者は攻撃ウィンドウ中（太平洋時間午前10:20から11:40）に残りの正常なノードをDDoSし、DVNのフェイルオーバーロジックを起動させ、汚染されたインフラのみに依存させました。このステップは、正常なノードが偽造された応答と矛盾する真実のデータを返していたため必要でした。

• ステップ5：DVNが攻撃者制御のデータのみを受け取るようになった状態で、偽造されたLayerZeroクロスチェーンメッセージが有効なものとして提示されました。DVNはEthereumの宛先エンドポイントでナンス308を証明しましたが、このナンスはUnichain上に対応するアウトバウンドイベントが存在しませんでした（ソースエンドポイントが最大アウトバウンドナンスとして307を報告したことで確認）。

• ステップ6：Ethereum側のrsETHアダプターは、有効に証明されたメッセージを受け取り、数時間前にTornado Cashを通じて事前に資金が供給されていた攻撃者の受信アドレス（0x8b1b6c...0d3b）へ116,500のrsETHをリリースしました。盗まれたトークンはすぐに7つのブランチウォレットに分散され、Aaveの担保ポジション、直接のETHスワップ、およびArbitrumへの再ブリッジを通じて清算されました。最終的な収益はEthereumの0x5d3919...7cccとArbitrum上の対応するコレクターアドレスに集約されました。

• ステップ7：悪意のあるバイナリは完了後に自己破壊ルーティンを実行し、すべてのローカルログと設定ファイルとともに自身を削除しました。これによりインシデント後のフォレンジック復旧が大幅に妨げられ、攻撃者の高度な運用能力が示されました。

• ステップ8：攻撃者が同じパスウェイを悪用して追加で40,000のrsETH（約$95M）を狙う試みは、KelpDAOが異常を検出してEthereumメインネットおよびL2上の関連するすべてのコントラクトを一時停止したことで阻止されました [2]。

広範な影響

被害は当初の$290Mのブリッジエクスプロイトをはるかに超えて広がりました。攻撃者は複数のマーケットにわたってAaveに約89,567のrsETH（約$221M）を預け入れ、E-Modeの93% LTVでWETHを借り入れました [4]。Aaveは正規にブリッジされたrsETHと偽造メッセージによってリリースされたトークンを区別できなかったため、「汚染された」担保は完全に有効なものとして扱われました。その結果生じたWETHリザーブのフリーズは、Ethereum、Arbitrum、Base、Mantle、Lineaにわたって伝播し、rsETHに全くエクスポージャーを持たないユーザーにも影響を与えました。このカスケード的な伝播は、単一のブリッジ設定の欠陥からマルチチェーンの貸出市場混乱に至るまで、DeFiのコンポーザビリティが単一障害点のリーチとコストの両方をいかに増幅させるかを示しています。

その後、分散化の運用上の現実について同様に重要な疑問が提起されました。LayerZero Labsは、そのDVNが1-of-1設定を使用するアプリケーションのメッセージに署名しなくなると発表しました [1]。これはプロトコルレベルの分散化だけでは、アプリケーションレベルの設定上の弱点を補完できないことを示唆しています。

チェーンレベルでは、Arbitrumセキュリティカウンシルが緊急措置を実行し、Arbitrum One上で攻撃者が保有していた30,766のETHをフリーズしました。BlockSecの分析によると [5]、これはチェーンレベルの強制状態遷移によって実現されました：セキュリティカウンシルはEthereumのインボックスコントラクトを一時的にアップグレードし、攻撃者のアドレスを偽装する未署名のL1からL2へのメッセージを注入し、元の実装を復元しました。これらはすべて保有者の署名を必要とせずに行われました [3]。

この措置はガバナンスで定義された緊急権限の正当な行使であり、法執行機関と連携して透明性をもって実施されました。しかしそれと同時に、L2チェーンが設計上、中央集権的な介入能力を維持していることも示しています：Arbitrum One上のいかなる資産も、原則として同じメカニズムを通じてセキュリティカウンシルが移動させることができます。システムの理論的な信頼モデルと実際の信頼境界の間のギャップは、このインシデントがあらゆる層において示しているように、最も重大なリスクが潜む場所です。

結論

このインシデントは、ブリッジのセキュリティをプロトコルの正確性だけに還元することはできないことを示しています。LayerZeroプロトコル自体は設計通りに機能しました；脆弱性は完全にその上のオペレーショナルレイヤーに存在していました。核心的な教訓は、オフチェーン検証インフラは信頼境界の一部であり、そのセキュリティ姿勢は保護する価値と一致していなければならないということです。

以下の3つの緩和策のいずれか一つでも、この結果を防ぐことができました：

• マルチDVN設定：複数の独立したDVN間でコンセンサスを要求することで、単一のDVNが完全に騙されたとしても、単一DVNの侵害だけではメッセージを承認するのに不十分となります。

• フェイルオーバーを考慮したRPC選択：アクティブな検証ウィンドウ中の到達可能ノードの突然の減少は、日常的な可用性イベントではなく潜在的な攻撃シグナルとして扱うべきです。DVN実装は、縮小されたノードセットで続行するのではなく、停止またはアラートを発すべきです。

• RPCインフラのハードニング：本番RPCノード上で実行中の実行ファイルを置き換える能力は、基盤となるサーバーのアクセス制御が不十分であることを示しています。DVNがソースチェーンのグラウンドトゥルースとして依存するインフラは、DVN署名インスタンス自体と同じセキュリティ境界に置かれるべきです。

より広く言えば、オフチェーン証明に依存するあらゆるブリッジまたはクロスチェーンプロトコルは、スマートコントラクトレイヤーだけでなく、ソースチェーンイベントから宛先チェーン実行に至るまでの完全なデータパイプラインを監査すべきです。数億ドルがそれに依存している場合、RPCインフラがデフォルトで信頼できるという前提はもはや維持できません。

参考文献

[1] LayerZero Labs、「KelpDAOインシデント声明」、2026年4月20日。https://x.com/LayerZero_Core/status/2046081551574983137

[2] KelpDAO、「4月18日インシデント：追加情報」、2026年4月21日。https://x.com/KelpDAO/status/2046332070277091807

[3] Arbitrum、「セキュリティカウンシル緊急措置」、2026年4月21日。https://x.com/arbitrum/status/2046435443680346189

[4] LlamaRisk、「rsETHインシデントレポート」、2026年4月20日。https://governance.aave.com/t/rseth-incident-report-april-20-2026/24580

[5] BlockSec、「ArbitrumセキュリティカウンシルフリーズメカニズムAnalysis」、2026年4月21日。https://x.com/Phalcon_xyz/status/2046467830498173088

今週のその他のインシデント

Rhea Finance

2026年4月16日、Rhea FinanceのNEAR上の融資・マージントレーディングプロトコルであるBurrowlandが、マージントレーディングモジュールのビジネスロジックの欠陥により約$18.4Mのエクスプロイトを受けました。レバレッジポジションを開く際、プロトコルはポジションを受け入れる前に期待されるスワップ出力を検証するためにverify_token_out()に依存しています。しかしこの関数は、トークンが最終出力トークンに一致するたびに中間スワップステップからのtoken_out量を誤って累積し、これらの中間量がその後token_inとして再利用されるという事実を考慮していませんでした。攻撃者は偽のトークンとプールをデプロイし、認識された出力量を膨らませてソルベンシーチェックを通過させる循環スワップパスを構築し、プロトコルから約$18.4Mを流出させました。

背景

BurrowlandはNEAR上のオープンソースの融資・マージントレーディングプロトコルです。標準的な供給と借入機能に加え、マージントレーディングをサポートし、ユーザーのレバレッジポジションを表す3つの主要変数を導入しています：token_c（担保）、token_d（債務資産）、token_p（ポジション資産）。

ロングポジションの場合、ユーザーはtoken_cを担保として預け、選択したレバレッジ（例：5倍）でtoken_dを借り入れます。借り入れたtoken_dはその後DEX上でユーザーがエクスポージャーを持ちたい資産であるtoken_pにスワップされます。通常の条件下では、受け取ったtoken_pの価値は費やされたtoken_dの価値とほぼ等しくなります。プロトコルはユーザーに代わってtoken_pを保有し、借り入れたtoken_dを債務として記録します。

ショートポジションの場合、ユーザーは同様にtoken_cを預け、レバレッジを使用してショートしたい資産であるtoken_dを借り入れます。借り入れたtoken_dは別の資産（token_p）にスワップされ、実質的にtoken_dへのショートエクスポージャーを取ります。ここでも、スワップは通常の市場条件下で価値を保持することが期待されます。

ポジションのライフサイクル全体を通じて、token_pはプロトコル内に保管され、ユーザーは直接引き出すことができません。損益を実現するにはポジションをクローズする必要があり、その時点でtoken_pは債務を返済するためにtoken_dにスワップバックされます。

マージンポジションのオープンはinternal_margin_open_position()によって処理され、ポジションパラメーターを設定してDEXへの借入をディスパッチします。

プロトコルが新しいポジションを受け入れる前に、4つの保護機能を順番に評価します：is_min_amount_out_reasonable()はPythオラクルが示唆するスワップ出力に対してユーザーが宣言したmin_token_p_amountを相互チェックしてスリッページを制限し、is_open_position_liquidatable()は期待されるポジションと担保の価値が清算ラインをクリアすることを確認し、is_open_position_forcecloseable()はアカウントが計算上すでに債務超過でないことを確認し、get_open_position_lr()はtoken_d/token_cの価値が最大レバレッジレートを超えないことを強制します。

スワップがまだ実行されておらず、実現済みの金額がないため、4つのチェックはすべてmin_token_p_amountをポジション資産の価値として使用します。したがって、すべてのゲートの正確性はmin_token_p_amountがDEXが実際に提供するものに束縛されているかどうかにかかっています。その束縛こそが、verify_token_out()（RefV1TokenReceiverMessage::get_token_out()を介して実装）がユーザーが提出するスワップメッセージに対して強制すべきものです。

脆弱性分析

欠陥はverify_token_out()内にあります。この関数は最後のスワップステップのtoken_outを最終出力トークンとして選択し、同じトークンを生成するすべてのスワップステップの宣言されたmin_amount_outを合計します。これは各生産が最終出力に貢献するという前提に基づいています。これは本物のマルチパス（スプリットルート）スワップには正しいですが、token_outが次のステップのtoken_inとして即座に消費されるステップを除外しません。A->B->A->Bのような往復パスでは、->Bステップの出力が次のB->Aステップで費やされてBurrowlandに到達しないにもかかわらず、すべての->Bステップが合計にカウントされます。verify_token_out()が承認する合計min_amount_outはもはやDEXが実際に返すものを表していません。

verify_token_out()がバイパスされると、膨らまされたmin_token_p_amountがinternal_margin_open_position()全体でグラウンドトゥルースとして扱われます。危険なオープンを停止するためのすべてのソルベンシーゲートが捏造された数値に対して計算されるため、ポジションは受け入れられ、プロトコルは循環スワップメッセージを添付してDEXへtoken_dをディスパッチします。

攻撃分析

以下の分析は、トランザクション GcXEKm...fnFT に基づいています。

フェーズ1：偽のトークンとプールのデプロイ

攻撃者は3つの偽のトークンをデプロイし、5つの偽のプールを作成しました。

1. 偽のトークンID：

   1. Fake1: 31623e1d98275d2b0db4f50e102f6bf40877c1345e06e4ca6727f58c89564bb2

   2. Fake2: 6a28e3d3c7af1415ec22c6264013e1138bab00f85b8b6055d882d7d46afdf49b

   3. Fake3: e081e03daf58f5bb04cf95a03017e58449b76e704f1974771d7e3bd52835b6e5

2. 偽のプールID：

   1. Zec-Fake1: 7509

   2. Fake1-Fake2: 7510

   3. USDC-Fake2: 7511

   4. Fake2-Fake3: 7512

   5. Fake3-USDC: 7513

フェーズ2：マージンポジションのオープン

• ステップ1：攻撃者はBurrowlandのマージントレーディング機能を使用して、正当な価値のある資産をtoken_c、実際のリザーブ資産をtoken_dとしてレバレッジポジションをオープンし、アクションリストがフェーズ1の攻撃者制御プールを経由したA->B->A->Bの往復となるスワップメッセージを添付しました。

• ステップ2：verify_token_out()が端末出力に一致するすべてのステップのmin_amount_outを合計するため、往復パスにより攻撃者は宣言されたmin_token_p_amountを任意の値に膨らませることができました。

• ステップ3：膨らまされたmin_token_p_amountはinternal_margin_open_position()のすべてのオープン時のヘルスチェックを通過し、ポジションは受け入れられ、プロトコルはRef-Financeへtoken_dをディスパッチしました。

• ステップ4：循環スワップはごくわずかな量のtoken_pを返すだけでした；on_open_trade_return()は再チェックなしにそれを記録し、ポジションは作成時から債務超過となりました。

• ステップ5：借り入れたtoken_dはパス沿いの攻撃者制御プール内に決済されました；攻撃者はremove_liquidity()を通じてそれを引き出しました。

• ステップ6：借入はレバレッジが掛かっているため、引き出されたtoken_dは預け入れたtoken_cより価値が高くなります。差額がサイクルごとの純利益であり、回収不能な債務はprotocol_debtsに強制クローズされます。攻撃者は約$18.4Mが流出するまでこの構造を繰り返しました。

結論

このインシデントはBurrowlandのマージンオープンパスにおけるビジネスロジックの欠陥によって引き起こされました。関数RefV1TokenReceiverMessage::get_token_out()は、これらの量が最終出力として残ると想定して、最終トークンに一致するたびに中間出力を誤って集約しました。しかし、循環スワップパスはこの前提を崩します。これらのトークンはパス内で再利用・消費される可能性があるためです。その結果、計算されたmin_token_p_amountは人為的に膨らまされる可能性があり、その後のすべてのソルベンシーチェックが誤った値に依存し、実際の受取量を検証せずに偽造されたヘルス状態に対してポジションをオープンすることが可能となりました。

本番のマージントレーディングコントラクトの開発者は以下を行うべきです：

• ユーザーが宣言したmin_amount_outを未検証の入力として扱い、最後のホップのmin_amount_outのみを取得するか、以前に生産されたtoken_outを再消費するスワップパス（ターゲットを経由するサイクルなし）を明示的に拒否する。

• 攻撃者が宣言された値を一方的に膨らませてソルベンシー述語をバイパスできないよう、宣言されたスリッページをオラクルが示唆するスワップ出力に対して下限と上限の両方でバインドする。

Hyperbridge

2026年4月13日、EthereumのクロスチェーンメッセージングブリッジであるHyperbridgeが、MMR（Merkle Mountain Range）証明検証ロジックにおける入力検証の欠如により約$242Kのエクスプロイトを受けました。関数MerkleMountainRange.VerifyProof()がleaf_index < leafCountを強制していなかったため、攻撃者はクロスチェーン証明を偽造し、1,000,000,000のDOTトークンのミントを含む特権的な操作を行うことができました。

背景

Hyperbridgeはクロスチェーンメッセージのために、Ethereum側の検証者とディスパッチャーモデルを使用しています。Ethereum上では、コントラクトHandlerV1が提供された証明を保存されたoverlayRootに対して検証し、証明が受理されると、コントラクトTokenGatewayなどの宛先モジュールにメッセージをディスパッチします。

コントラクトTokenGatewayは特権的な資産管理モジュールです。通常の資産ブリッジングに加え、資産の作成、登録解除、管理者管理などのガバナンス的な操作もサポートしています。ERC6160Ext20として実装されたブリッジ資産の場合、管理者はchangeAdmin()を呼び出してミント権限を直接移譲でき、新しい管理者はmint()を通じて任意の供給量をミントできます。

これはアセットブリッジ全体の安全性がHandlerV1の証明検証パスの正確性に依存することを意味します。偽造されたメッセージが検証を通過できれば、ダウンストリームモジュールは攻撃者制御のペイロードを正真正銘のクロスチェーン命令として扱います。

脆弱性分析

コアとなる問題は、コントラクトHandlerV1（0x6c84ed...6d64）のMMR証明検証フローにあります。エントリー関数handlePostRequests()はまず攻撃者が提供した入力に基づいてMmrLeaf(leaf.kIndex, leaf.index, commitment)を構築します。その後、証明検証を実行するためにMerkleMountainRange.VerifyProof()が呼び出されます。

MerkleMountainRange.VerifyProof(root, request.proof.multiproof, leaves, request.proof.leafCount)

しかしVerifyProof()はroot == CalculateRoot(proof, leaves, mmrSize)のみをチェックし、各leaf.indexが範囲内（つまりleaf.index < leafCount）であることを検証しません。leafCount = 1とleaf_index = 1を選択することで、攻撃者はCalculateRoot()が偽造されたリクエストコミットメントを計算されたルートに折り込むことをスキップさせ、ピークルートを直接返させます。これによりメッセージと証明の束縛が壊れ、任意のペイロードが過去のoverlayRootに対して有効として通過できるようになります。

攻撃分析

以下の分析は、トランザクション 0x240aeb...1109 に基づいています [1]。

• ステップ1：攻撃者のEOA 0xC513...F8E7は同じトランザクション内でヘルパーコントラクト0x518A...8f26と0x31a1...ca9ABをデプロイしました。

• ステップ2：ヘルパーコントラクト0x31a1...ca9ABはHandlerV1の脆弱な検証パスを通じて偽造されたリクエストを提出しました。VerifyProof()が範囲外のleaf_indexを拒否しなかったため、偽造されたリクエストコミットメントはルート計算から省略されましたが、証明は過去のoverlayRootと一致しました。

• ステップ3：偽造メッセージが受け入れられた後、HandlerV1はそれをTokenGatewayにディスパッチし、ChangeAssetAdminアクションを実行しました。これによりDOTトークンの管理者が攻撃者制御のヘルパーコントラクト0x31a1...ca9ABに変更されました。

• ステップ4：ヘルパーコントラクトは1,000,000,000e18のDOTトークンをミントしました。

• ステップ5：ヘルパーコントラクトはOdos Router V3を通じて新たにミントされたDOTトークンを108.2のETHにスワップしました。

• ステップ6：攻撃者はEOAアカウントに108.2のETHを送金しました。

結論

このインシデントはHyperbridgeのMMR検証ロジックにおける不適切な証明検証によって引き起こされました。leaf_index < leafCountが強制されていなかったため、攻撃者はそのコミットメントが計算されたルートに実際には含まれていないメッセージを偽造できましたが、それでも過去の状態ルートに対して検証を通過できました。緩和策として、証明検証の前にleaf_index < leafCountなどの厳格な境界チェックを強制すべきです。

参考文献

[1] BlockSec、「Hyperbridge攻撃分析」、2026年4月13日。https://x.com/Phalcon_xyz/status/2043601549893738970

Dango

2026年4月13日、Cosmos AppChainとして構築された無期限先物DEXのDangoが、符号チェックの欠如により約$1.5Mのエクスプロイトを受けました。関数replenish_insurance_fund()は入力量の検証にis_positive()の代わりにis_non_zero()を使用しており、攻撃者は負のUsdValueを提供して保険基金をマージンポジションに流出させることができました。

背景

DangoはCosmos AppChainとして構築された無期限先物DEXです。ユーザーはperpsコントラクトに担保としてUSDCを預け、オンチェーンの中央指値注文板（CLOB）を通じてBTC、ETH、SOLなどの資産でレバレッジロングまたはショートポジションをオープンします。各ユーザーの担保残高はperpsコントラクト内のマージンアカウントとして追跡されます。

流動性プロバイダー（LP）を不良債権損失から守るために、プロトコルは保険基金を維持しています：これはperpsコントラクト内に保持されたUSDCのリザーブで、清算されたポジションの担保がその債務を完全に返済するのに不十分な場合の不足分を補います。これがなければ、そのような不足分はLPに直接社会化されます。すべてのユーザーは自分のperpアカウントからのマージンを保険基金に提供することができました。

脆弱性分析

根本原因はコントラクト 0x90bc84...bea4f の関数replenish_insurance_fund()にあり、負の入力量を拒否できていませんでした。この関数には2つのガードがありますが、どちらも負のamountを止めることができません：

1. ensure!(amount.is_non_zero())はamountがゼロでないことをチェックしますが、正であるかどうかはチェックしません。
2. ensure!(user_state.margin >= amount)はユーザーが十分なマージンを持っているかチェックしますが、正のマージンはどれも>= 負の数を満たします。

両方のガードを通過すると、関数はuser_state.margin.checked_sub_assign(amount)とstate.insurance_fund.checked_add_assign(amount)を実行します。amountが負の場合、それを引くことでユーザーのマージンが増加し、それを加算することで保険基金が減少し、意図した資金フローが完全に逆転します。

攻撃分析

トランザクション：

フェーズ1：

Tx 1で、攻撃者はDangoの保険基金から資産を流出させるために以下のステップを実行しました：

• ステップ1：攻撃者は1e6のUSDCを預け入れてマージンポジションをオープンしました。これはreplenish_insurance_fund()を呼び出すための前提条件でした。

• ステップ2：攻撃者は負のamount（つまり-1500000）でreplenish_insurance_fund()を呼び出しました。不適切な検証により、負のamountが受け入れられ、保険基金から攻撃者のマージンポジションへ資産が流出しました。

• ステップ3：攻撃者はマージンポジションからすべての資産を引き出し、$1,500,000のUSDCを獲得しました。

フェーズ2：

Tx 2-8で、攻撃者はtransfer_remote()を呼び出して盗んだ資産をEthereumにブリッジしました。その結果、$410,000のUSDCがEthereumにブリッジされました。

結論

この攻撃の本質は、符号ガードなしに符号なしコンテキストで使用された符号付き整数型です。UsdValue型は設計上符号付きです（perpsのPnLは負になり得る）が、保険基金への寄付パスウェイは正の貢献のみが意味を持ちます。is_positive()の代わりにis_non_zero()を使用することで、誰でも資金フローの方向を反転させ、保険基金からUSDCを自分のマージンに流出させることができる一語分のギャップが残されました。攻撃者は単一トランザクション（$1を預け入れ、$1.5Mを流出させ、$1,500,001を引き出す）で攻撃全体を実行し、その後ゆっくりと資金をブリッジしました。ブリッジのレート制限が被害を制限した唯一のメカニズムでした：それがなければ、約$1.5M全体が回収不能な形でEthereumにブリッジされていたでしょう。

BlockSecについて

BlockSecはフルスタックのブロックチェーンセキュリティおよび暗号資産コンプライアンスプロバイダーです。私たちはプロトコルやプラットフォームのライフサイクル全体を通じて、コード監査（スマートコントラクト、ブロックチェーン、ウォレットを含む）、リアルタイムの攻撃遮断、インシデント分析、不正資金のトレース、AML/CFT義務の遵守をお客様が行えるよう支援する製品とサービスを構築しています。

BlockSecは著名な学術会議で複数のブロックチェーンセキュリティ論文を発表し、DeFiアプリケーションのゼロデイ攻撃をいくつか報告し、2,000万ドル以上を救うために複数のハックをブロックし、数十億ドルの暗号資産を保護してきました。

• 公式ウェブサイト：https://blocksec.com/

• 公式Twitterアカウント：https://twitter.com/BlockSecTeam

• 🔗 BlockSec監査サービス : リクエストを送信

• 🔗 Phalcon Security APP: デモを予約

• 🔗 Phalcon Compliance