Web3セキュリティインシデント週次まとめ | 2026年3月2日～3月8日

過去1週間（2026年3月2日～2026年3月8日）、BlockSecは7件の攻撃インシデントを検知・分析し、総損失額は約325万ドルと推定されます。以下の表にこれらのインシデントの概要を示し、各ケースの詳細な分析は後続のサブセクションで提供します。

1. BUBU2インシデント

概要

2026年3月1日、BNB Chain上のBUBU2トークンが侵害され、約19.7Kドルの損失が発生しました。根本原因はトークン設計上の欠陥でした。コントラクトには、転送時にAMMペアの準備金から直接トークンを差し引く、時間経過でデフレが進むメカニズムが組み込まれていました。攻撃前にコントラクト所有者がトリガー間隔を不当に短い値に短縮したため、数百回のバーンラウンドが蓄積され、単一の呼び出しで実行されました。攻撃者はフラッシュローンを利用してこのメカニズムをトリガーし、ペアの準備金を崩壊させ、トークン価格をインフレさせた後、歪んだレートで逆スワップして利益を得ました。

背景

BUBU2はBNB Chainにデプロイされたデフレ型ERC-20トークンプロトコルです。このプロトコルには、burnAndMintSwitchによって制御される周期的なデフレエンジンが組み込まれています。所有者がsetBurnAndMintSwitch(true)を介してこれを有効にすると、_update()フックをトリガーする許可された非転送はすべて_triggerDailyBurnAndMint()を呼び出します。これは、最後のトリガー以降に経過したTRIGGER_INTERVAL期間の数に比例して、取引ペアのBUBU2残高からトークンをバーンし、それに応じて準備金を同期します。

脆弱性分析

根本原因は、BUBU2トークンコントラクト（0x3fF3...ee52）の設計上の欠陥です。コントラクトには、_update()フックに周期的なデフレメカニズムが組み込まれています。トリガーされると、_triggerDailyBurnAndMint()は、最後の実行以降に経過したTRIGGER_INTERVAL期間の数を計算し、取引ペア（0x7745...cd2f）から直接BUBU2を比例配分でバーンし、その後sync()で準備金を更新します。重要なのは、所有者がロックタイムや最小値保護なしにTRIGGER_INTERVALを再構成できることです。

攻撃前、所有者はsetBurnAndMintSwitch(true)を呼び出し、次にsetTriggerInterval(120)を呼び出して、デフォルトの6時間から120秒に間隔を圧縮しました。lastTriggerTimeはまだ数時間前のままだったため、次のトリガーは数百回の累積ラウンドを計算し、バーン量はラウンド数に比例しました。これにより、単一の転送でペアから大量のBUBU2が引き出され、準備金が崩壊し、トークン価格が約11倍にインフレしました。

攻撃分析

以下の分析は、トランザクション0x1bc0...141c、0x191c...1ee4、0xd6e5...51a6に基づいています。

• ステップ1：トークン所有者はまずsetBurnAndMintSwitch(true)を介して周期的なデフレメカニズムを有効にし、次にsetTriggerInterval(120)を介してトリガー間隔をデフォルトの6時間から120秒に短縮しました。その後、攻撃者は18 WBNBをフラッシュローンで借り入れ、約18,715,856 BUBU2をプールからスワップしました。

  

  

• ステップ2：攻撃者は小さな転送を開始し、_triggerDailyBurnAndMint()をトリガーしました。sync()が実行された後、プールからのBUBU2残高は約1,025,988,664e18トークン減少し、準備金には6,493,352e18 BUBU2のみが残りました。これにより、BUBU2価格は約200倍にインフレしました。

  

  

  

• ステップ3：攻撃者はステップ1で取得したBUBU2をインフレした価格でプールに売り戻し、約50 WBNBを受け取りました。フラッシュローンを返済した後、純利益は約32 WBNBでした。

結論

BUBU2の侵害は、トークンコントラクトの重大な設計上の欠陥に起因しました。所有者が不当に短いTRIGGER_INTERVALを設定したため、経過時間が数百ラウンドに蓄積し、単一の呼び出しで取引ペアの準備金が枯渇し、BUBU2価格の急激な急騰を引き起こしました。

将来同様のリスクを軽減するために：

• TRIGGER_INTERVALのような重要なパラメータを、範囲またはタイムロックで保護してください。

• 累積実行ラウンドを制限またはキャップしてください。

2. ACPRouteインシデント

概要

2026年3月2日、Base上のACPRouteプロトコルが侵害され、約58Kドルの損失が発生しました。根本原因は、支払いマネージャーコントラクトにおけるビジネスロジックの不備でした。ジョブの状態はストレージ参照ではなくメモリコピーとしてロードされたため、累積的な支払い追跡はオンチェーンに永続化されませんでした。これにより、攻撃者はジョブを作成し、フェーズ遷移中に自動支払いリリースをトリガーした後、権限のないクレーム機能を通じて同じエスクロー資金を再度請求することができました。

背景

ACP（Agent Commerce Protocol）は、クライアントとプロバイダーのインタラクションのために設計されたモジュラーオンチェーンコマースプロトコルです。アクティビティを3つのレイヤー（アカウント、ジョブ、メモ）で構成します。ジョブは固定のライフサイクル（REQUEST → NEGOTIATION → TRANSACTION → EVALUATION → COMPLETED）に従い、支払いはTRANSACTIONフェーズ中にPaymentManagerコントラクトによってエスクローされます。ジョブがCOMPLETEDに達すると、プロトコルはreleasePayment()関数を介してプロバイダーにエスクローされた資金をリリースします。二重請求を防ぐため、プロトコルはJob構造体上のamountClaimedフィールドを使用してジョブごとの累積支払いを追跡します。releasePayment()関数の各呼び出しは、資金が一度だけリリースされることを保証するために、要求された金額とamountClaimedを比較することが期待されます。

脆弱性分析

根本原因は、PaymentManagerコントラクト（0x56c3...0684）のreleasePayment()関数にあります。この関数では、ジョブの状態がストレージ参照ではなくメモリコピーとしてロードされています。プロトコルは二重請求を防ぐためにamountClaimedを介して累積支払いを追跡しますが、インクリメントjob.amountClaimed += amountは一時的なローカルコピーのみで動作し、オンチェーンストレージには書き戻されません。結果として、releasePayment()関数のすべての呼び出しはamountClaimed == 0を観測するため、攻撃者はclaimBudget()関数を呼び出し、フェーズ遷移が既にreleasePayment()関数を自動的にトリガーした後、被害者コントラクト（0x307e...d6e8）から2度目の資金引き出しが可能になります。

攻撃分析

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

• ステップ1：攻撃者は、その後の攻撃のための資本として、フラッシュローンで97,000e6 USDCを借入しました。

• ステップ2：コールバック内で、攻撃者はACPRouterのcreateJob()関数を呼び出し、その際、資金を受け取るために新規のプロバイダーコントラクト（0x1ee502dd...）をデプロイしました。

• ステップ3：攻撃者はcreateMemo()関数を繰り返し呼び出し、プロバイダーコントラクト自体のexec()を呼び出してジョブフェーズを進めました。COMPLETEDフェーズ遷移がトリガーされ、releasePayment()関数が自動的に呼び出されて、プロバイダーコントラクトに全残高がリリースされるまで行いました。この時点でamountClaimedは更新されるべきでしたが、ストレージ内の値は0のままでした。

• ステップ4：攻撃者はclaimBudget()関数を呼び出し、エスクローされた97,000e6 USDCを2度目に請求し、利益として確保しました。

結論

このインシデントは、同じジョブライフサイクル内でエスクローされた資金を2度請求することを可能にした状態永続化の欠陥によって引き起こされました。

同様のリスクを将来軽減するために：

• amountClaimedのような重要な状態変数がストレージ参照を使用して更新されることを保証してください。

• 機密性の高い支払い関数を制限するか、実行前に厳格な状態検証を強制してください。

3. sDOLA Llamalendマーケットインシデント

概要

2026年3月2日、Ethereum上のsDOLA Llamalendマーケットが侵害され、約239Kドルの損失が発生しました。根本原因は価格操作です。具体的には、sDOLAはdonate()を介して価格操作が可能なERC4626トークンです。LlamalendはAMMベースの貸付市場であり、LLAMMAのメカニズムにより、担保価格が上昇してもユーザーは清算される可能性があります。したがって、攻撃者はdonate()を使用してsDOLA価格を押し上げ、ユーザーのポジションヘルスをゼロ未満にし、その後それらのユーザーを清算して利益を得ることができます。

背景

LLAMMA（Lending-Liquidating AMM Algorithm）は、Curve [1]で使用されているAMMベースの貸付市場です。従来の貸付プロトコルとは異なり、LLAMMAはユーザーの担保をAMM内の価格帯に配置します。オラクル価格$P{}_{oracle}P\backslash \backslash \_\{oracle\}$が変動すると、担保はバンド間のアービトラージ駆動スワップを介して、担保トークンとcrvUSDの間で徐々に変換され（ソフト清算）、突然の清算をトリガーするのではなく、徐々にポジションのリスクを低減します。

ソフト清算がポジションのリスクを十分に迅速に低減できない場合、ハード清算が開始されます[2]。これは、ポジションのヘルスがゼロ未満に低下した場合にトリガーされます。ヘルスはget_x_down() [3]を介して計算されますが、これは単に担保を市場価格にするわけではありません。代わりに、ユーザーのポジションの回収可能価値を評価するために、ラウンドトリップ変換をシミュレートします。このラウンドトリップは、2つの異なる価格アンカーを使用します。1つは現在の$P{}_{oracle}P\backslash \backslash \_\{oracle\}$（ライブオラクルと連動して動く）から派生し、もう1つはユーザーのバンド境界（ポジションが作成されたときに固定される）から派生します。

脆弱性分析

バグのあるコントラクトには、crvUSD Controller（0xad44...fb86）とLLAMMA AMM（0x0079...a1f7）が含まれます。被害者コントラクトはsDOLA Llamalendマーケット（0x2b08...4fbe）です。

sDOLAは、そのシェア価格が総資産と総シェアの比率によって決定されるERC4626ボールトトークンです。誰でもdonate()を呼び出してボールトに資産を追加できるため、単一のトランザクション内でシェア価格をインフレさせることができます。これはLLAMMAのヘルス機能が依存する操作可能なオラクルです。

背景で説明されているように、get_x_down()は2つの価格アンカー（動的、ライブオラクルと連動して動く）と（静的、ポジション作成時に固定される）の2つの価格アンカーを介したラウンドトリップ変換をシミュレートすることによってヘルスを計算します。プロトコルは、$P{}_{oracle}P\backslash \backslash \_\{oracle\}$を読み取る際に遅延や正常性チェックを適用しません。したがって、$P{}_{oracle}P\backslash \backslash \_\{oracle\}$がインフレすると、動的アンカーは上昇しますが、静的アンカーは変わりません。実際には、シミュレーションにより、インフレしたオラクル価格でcrvUSDが担保に変換され、元のバンド価格で戻されるため、2つのアンカー間のギャップが広がるにつれて評価される回収可能価値は減少します。これにより、担保価格が上昇しているにもかかわらず、ヘルスがゼロ未満になります。

攻撃分析

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

• ステップ1：LLAMMAの状態（大規模スワップ）を操作してactive_bandを移動させ、多くのユーザーをxのみの姿勢（crvUSDのみ）に追い込みました。

  

• ステップ2：寄付を介してsDOLAの価格を操作し、その後ゼロ額スワップ（swap(0)）を使用して操作された価格をAMMプールに書き込みました。

  

  

• ステップ3：users_to_liquidate() → _health() → get_x_down()を介してヘルス再計算をトリガーしました。

• ステップ4：get_x_down()は、2つの異なる価格アンカー（動的アンカー、現在インフレしている）と（静的アンカー、変更なし）を介して回収可能価値を計算するため、ラウンドトリップ変換は実効価値のカットを引き起こし、多くのポジションがゼロヘルスを下回りました。

• ステップ5：バッチハード清算でそれらのユーザーから利益を得ました。

さらに、トレースには2つのcreate_loan()呼び出しが含まれています。最初のローンは主に大規模なcrvUSDスワップ操作の資金調達に使用されました。2番目のローンは、最初のポジションの負債を返済し、資本をリサイクルするためにcrvUSDを取得するために使用されました。これらの2つのローンは主に資金調達/決済レグであり、コアの侵害ステップではありません。

結論

このインシデントは、同じジョブライフサイクル内で担保価格操作攻撃によって引き起こされました。攻撃者はインテキを操作し、LLAMMAのパスベースのヘルスメカニズムにより、ユーザーを清算条件に追い込みました。重要な結果は、担保価格が上昇してもポジションが清算可能になる可能性があることです。推奨される強化方向：

• 清算に遅延またはTWAP担保価格を使用してください。

参照

• [1] Curve crvUSD LLAMMAドキュメント：https://dev.curve.finance/crvUSD/amm/#bands

• [2] Curve LLAMMA清算説明：https://dev.curve.finance/crvUSD/llamma-explainer/#liquidation

• [3] Curveステーブルコインホワイトペーパー：https://docs.curve.finance/pdf/whitepapers/whitepaper_curve_stablecoin.pdf

4. z0r0zによるV4ルーターインシデント

概要

2026年3月3日、Ethereum上のz0r0zによるV4ルーターが侵害され、約42Kドルの損失が発生しました。攻撃はswap()における不正な承認ロジックによって引き起こされました。ルーターはインラインアセンブリの固定されたコールデータオフセットに依存して、支払者がmsg.senderと一致することを確認しました。動的型に対するABIエンコーディングは固定レイアウトを保証しないため、攻撃者は非標準だが有効なコールデータを構築してチェックをバイパスし、以前に承認された被害者を支払者として偽装し、スワップ出力を攻撃者管理アドレスにリダイレクトすることができました。

背景

プロトコルはUniswap v4 Routerから継承し、そのメソッドの一部をオーバーライドしています。本質的には、スワップルーターとして機能し、ユーザーが対応するプールと直接やり取りするのを避け、ルーターを統一されたエントリポイントとして使用できるようにします。

脆弱性分析

根本原因は、V4 Routerコントラクト（0x0000...ce97）のビジネスロジックの不備です。被害者コントラクトは0x65a8...7675です。swap()関数は2つのパラメータ、data（バイト）とdeadline（uint256）を受け取ります。関数内では、承認チェックがインラインアセンブリブロックを使用してcalldataload(164)とcaller()を比較し、dataにエンコードされた支払者がmsg.senderと一致することを確認します。プロトコルは、バイトオフセットが常に0x40であり、支払者がバイト位置164（0xa4）にあると想定しています。

しかし、ABIエンコーディングはこのレイアウトを保証しません。動的パラメータはヘッドにオフセットのみを格納し、そのオフセットはコールデータ内の任意の揃えられた場所に合法的にポイントできます。バイトオフセットを0xc0に移動させる有効だが非標準なエンコーディングを構築することにより、攻撃者はヘッドと実際のテール間に任意のパディングを挿入できます。攻撃者はバイト位置164に自身のアドレスを配置してアセンブリチェックを通過させ、一方、移動したテールにある実際のバイトペイロードは、被害者のアドレスを支払者としてエンコードします。以前にルーターを承認した被害者を選択し、レシーバーを自身のアドレスに設定することで、攻撃者はスワップ出力をリダイレクトして資金を盗むことができます。

攻撃分析

以下の分析は、トランザクション0xfe34...466aに基づいています。

• ステップ1：以前にルーターを承認したユーザーをターゲットとして選択しました。

• ステップ2：承認チェックをバイパスするようにコールデータを構築しました。

• ステップ3：データ内で被害者を支払者として指定し、攻撃者自身のアドレスをトークンレシーバーとして設定し、その後被害者の資産を盗みました。

結論

このインシデントは、スワップパスにおけるハードコーディングされたコールデータオフセットへの依存によって引き起こされました。動的型に対するABIエンコーディングは固定レイアウトを保証しないため、攻撃者は非標準だが有効なコールデータでチェックをバイパスし、承認された被害者を支払者として偽装し、スワップ出力をリダイレクトしました。

同様のリスクを将来軽減するために：

• 動的ABIエンコードされたパラメータの認証にハードコーディングされたコールデータオフセットを使用しないでください。

• 手動の相対位置の想定ではなく、正規のABIデコーディングを使用して構造化された入力をデコードおよび検証してください。

• 実際の支払者、レシーバー、およびトークンフローが、意図された呼び出し元および実行コンテキストに対して一貫して検証されることを確認してください。

5. BitcoinReserveOfferingコントラクトインシデント

概要

2026年3月5日、Ethereum上のBitcoinReserveOfferingコントラクトが侵害され、約270万ドルの損失が発生しました。根本原因はビジネスロジックの不備でした。完全なERC-3525 SFTデポジットを処理する際、ミントロジックが転送コールバック中に一度、メインフローで一度と、単一の呼び出しで2回実行されました。攻撃者はこの二重ミント動作を繰り返しバーン＆ミントサイクルを通じて悪用し、BROトークン残高を指数関数的にインフレさせた後、超過分をredeemしてSolvBTCで利益を実現しました。

背景

BitcoinReserveOfferingは、ERC-3525 SFTポジションを譲渡可能なERC-20 BROトークンに変換するラッパーコントラクトです。ユーザーはmint()関数を呼び出して適格なSFTをデポジットでき、コントラクトは設定された交換レートに基づいて対応する量のBROをミントします。ユーザーがSFTの価値の一部のみをデポジットした場合、コントラクトは指定された量を内部保有ポジションに転送し、その後対応する価値のBROをミントします。ユーザーが完全なSFTをデポジットした場合、コントラクトはトークン全体をラッパーコントラクトに転送し、SFTの総価値に基づいてBROをミントします。ユーザーは後でburn()関数を呼び出してBROを対応するERC-3525 SFTポジションに償還でき、ラップされたERC-20価値をSFTポジションに戻すことができます。

脆弱性分析

根本原因は、BitcoinReserveOfferingコントラクト（0x15f7...cfcf）が、mint()関数で完全なERC-3525 SFTデポジットを処理する際に、ミントロジックを2回実行することです。具体的には、amount_ == sftBalanceブランチでは、mint()はERC3525TransferHelper.doSafeTransferIn()を呼び出して、SFT全体を安全にコントラクトに転送します。これによりonERC721Received()コールバックがトリガーされます。このコールバック内で、コントラクトは既にSFTの価値を計算し、送信者にBROをミントします。コールバックが戻った後、mint()は実行を続行し、同じamount_を使用して価値を再計算し、2回目の_mint(msg.sender, value)操作を実行します。この二重ミント動作により、攻撃者はバーン・ミントループを繰り返すことで、BRO残高を指数関数的にインフレさせることが可能になります。

攻撃分析

以下の分析は、トランザクション0x44e6...958dに基づいています。

• ステップ1：攻撃者は、シード資本として135e18 BROトークンを攻撃コントラクトに転送しました。

• ステップ2：攻撃者は次のループを実行しました：

1. 135e18 BROトークンをSFTトークンにラップしました。

2. 完全なSFT値でmint()を呼び出しました。これによりonERC721Received()コールバックがトリガーされ、135e18 BROトークンがミントされました。外側のmint()はその後続行され、再度_mint()が呼び出され、合計270e18 BROトークンの二重ミントが発生しました。

3. 270e18 BROトークンをSFTトークンにラップし直しました。

• ステップ3：ステップ2を22回繰り返した後、攻撃者は約567,758,816e18 BROトークンを蓄積し、最終的に38e18 SolvBTCを利益として償還しました。

結論

このインシデントは、完全なSFTデポジット中の二重ミントによって引き起こされ、攻撃者は繰り返しバーン・ミントサイクルを通じてBRO残高を指数関数的にインフレさせ、超過分をSolvBTCで償還することができました。

同様のリスクを将来軽減するために：

• デポジット操作ごとに資産会計が一度だけ行われることを保証してください。

• ミント額が基礎となるデポジット価値を超えないように、不変チェックを追加してください。

6. MoltEVMインシデント

概要

2026年3月7日、Base上のMoltEVMプロトコルが侵害され、約127Kドルの損失が発生しました。根本原因はトークンコントラクトにおける不完全なアクセス制御ロジックでした。特権ミント関数は、特定のインターフェースを持つコントラクトであるかどうかのみをチェックするモディファイアによって保護されていましたが、これは容易に偽装可能でした。攻撃者は悪意のあるコントラクトをデプロイしてチェックをバイパスし、大量のトークンをミントし、それを流動性プールにダンプして利益を得ました。

背景

MoltEVMは、自己複製トークンモデルを探求する、Baseにデプロイされた実験的なERC-20トークンプロトコルです。このシステムでは、一定の準備金しきい値に達すると、トークンは新しい子トークン（「Moltling」トークン）を生成できます。新しいMoltlingが作成されると、初期トークン供給がmintFromSpawner()関数を介して配布され、流動性が自動的にシードされて新しいトークンの取引市場が確立されます。この設計により、プロトコルはトークン系統を自律的に拡張でき、各世代のトークンがさらに子孫を生成する能力を持ちます。

脆弱性分析

脆弱性は、MoltEVMコントラクト（0x225d...501f）のmintFromSpawner()およびsetExemptFromSpawner()関数のアクセス制御ロジックにあります。両方の関数はonlySpawnerTokenモディファイアに依存していますが、これはプロトコルによって生成された正当なMoltlingコントラクトへの呼び出しを制限することを意図していました。

しかし、モディファイアは2つの弱いチェックのみを実行します。msg.senderがコントラクトであり、呼び出し元でinitialized()を呼び出すとtrueが返されることを確認します。これらの条件は任意のコントラクトが同じインターフェースを実装することで容易に満たすことができるため、チェックは正当なスPawnerトークンの意味のある認証を提供しません。

結果として、攻撃者はtrueを返す単一のinitialized()関数を実装する最小限のコントラクトをデプロイできます。デプロイ後、悪意のあるコントラクトはmintFromSpawner()を自由に呼び出して任意の量のトークンをミントでき、またsetExemptFromSpawner()を呼び出して攻撃者管理アドレスをホワイトリストに登録することもできます。これにより、攻撃者は実質的にミントパスの完全な制御を得られ、新しくミントされたトークンを流動性プールにダンプして利益を得ることが可能になります。

攻撃分析

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

• ステップ1：攻撃者は、trueを返すようにハードコーディングされた単一のinitialized()関数を実装する最小限のコントラクトをデプロイしました。これはonlySpawnerTokenモディファイアチェックを通過するのに十分でした。

• ステップ2：攻撃者のコントラクトは、同じ脆弱なonlySpawnerTokenモディファイアによって保護されているsetExemptFromSpawner()関数を呼び出して、攻撃者のアドレスを税金免除ホワイトリストに追加しました。これにより、その後の大規模なトークンダンプが売却税や内部スワップロジックをトリガーせず、利益が最大化されることが保証されました。

• ステップ3：攻撃者は、まずmEVMに対して、次にCSPAWN、CCUTTL、LWORM、NHYDRAを含む複数のMoltling子トークンに対して、setExemptFromSpawner() + mintFromSpawner()関数シーケンスを繰り返し実行し、すべてのターゲットにわたってトークンをバッチミントし、それぞれの流動性プールにダンプして利益を抽出しました。

結論

このインシデントは、特権ミントおよび設定関数に対する不十分なアクセス制御により、攻撃者が正当なSpawnerを偽装し、利益のために任意のトークンをミントすることを可能にしました。

同様のリスクを将来軽減するために：

• 特権ミントまたは設定関数に厳格なアクセス制御を強制してください。

• 認証のために容易に偽装可能なコントラクトチェックへの依存を避けてください。

• 明示的なホワイトリストまたは信頼できるコントラクトレジストリを介して呼び出し元IDを検証してください。

7. LEDSインシデント

概要

2026年3月8日、BNB Chain上のLEDSトークンが侵害され、約64Kドルの損失が発生しました。根本原因はビジネスロジックの不備でした。トークンコントラクトは複数の独立したデフレメカニズムを公開しており、それぞれが流動性ペアから直接トークンをバーンする能力があり、いずれもアクセス制御やクールダウンで保護されていませんでした。攻撃者は単一のトランザクション内で全てのバーンパスを連鎖させ、ペアのLEDS準備金をほぼゼロに崩壊させ、その後逆スワップを実行して不均衡なプールから資金を吸い上げ、利益を得ました。

背景

LEDSはBNB Chain上のデフレ型トークンであり、組み込みのフィーオン・トランスファーメカニズムを備えています。_transfer()は、供給を徐々に減らし、価格をサポートするように設計された複数のバーンメカニズムを実装しています。日次バーン関数triggerDailyBurnAndMint()、セルによるstor_18蓄積による遅延バーン、およびスワップレシーバーがPancakeSwap Routerに設定されている場合にトークンを0xdeadにバーンする特別なブランチです。トークンには、ユーザーがBNBを送信してLEDSをミントし、流動性を提供するdeposit()関数もあり、ディストリビューターを通じて請求可能なLP報酬を獲得します。

脆弱性分析

根本原因は、LEDSトークンコントラクト（0xfb62...a48f）のビジネスロジックの不備です。被害者はLEDS/WBNBペア（0xd109...6f3f）です。トークンは複数のデフレメカニズムを実装しています。triggerDailyBurnAndMint()、セルパスstor_18蓄積、および_transfer()のto == routerバーンブランチです。これらはそれぞれ独立して流動性ペアからLEDSを削除し、sync()を呼び出して準備金を更新します。

個々にこれらのメカニズムが段階的なデフレツールとして機能する一方で、単一のトランザクション内で連鎖させて効果を倍増させることができます。さらに、公開関数0x17a06174()により、誰でも蓄積されたstor_18残高全体を、アクセス制御やレート制限なしにいつでもフラッシュできます。これらのバーンパスを順番に積み重ねることで、攻撃者はペアのLEDS準備金をほぼゼロに減らすことができますが、WBNB準備金はそのままにして、逆スワップによって悪用可能な極端な価格乖離を引き起こすことができます。

攻撃分析

以下の分析は、トランザクション0x2608...79daに基づいています。

• ステップ1：攻撃者はフラッシュローン（Moolah + Venus collateral borrowing + Aave + PancakeSwap V4）を介して大量のWBNBを取得しました。

• ステップ2：複数のdeposit()呼び出しを実行してLP報酬を蓄積し、その後triggerDailyBurnAndMint()をトリガーしました。これにより、ペアからLEDSの一部がバーンされ、報酬がディストリビューターに送信され、プール内のLEDS準備金が減少しました。

• ステップ3：関数0xde1b1942()を呼び出して、蓄積されたLEDSトークン報酬を請求しました。

• ステップ4：請求したLEDSをWBNBに売却しました。売却後、ペアのLEDS残高がしきい値を超えたため、転送された金額はstor_18（保留中のバーン）に蓄積されました。

• ステップ5：レシーバーをRouterアドレスに設定してPancakeSwap経由でLEDSを購入しました。これにより、_transfer()の特別なブランチがトリガーされ、購入したLEDSがペアから0xdeadに直接バーンされ、プール内のLEDS準備金がさらに減少しました。

• ステップ6：関数0x17a06174()を呼び出しました。これにより、stor_18の全残高（ステップ4で蓄積されたもの）がペアから0xdeadにバーンされ、sync()が呼び出され、プールのLEDS準備金がわずか2 weiに崩壊しました。

• ステップ7：逆スワップを実行して、現在著しく不均衡なプールからWBNBを吸い上げ、全てのフラッシュローンを返済し、104.56 WBNB（64Kドル）の利益を上げました。

結論

このインシデントは、単一のトランザクション内で連鎖して流動性ペアの準備金を壊滅的に枯渇させる可能性のある、保護されていない複数のデフレメカニズムによって引き起こされました。

デフレまたは自動バーンメカニズムを実装するすべてのトークンコントラクトについて、開発者は以下を行うべきです：

• 適切なアクセス制御、レート制限、またはクールダウン強制なしに、ペアからのバーン関数を公開しないでください。

• 単一のトランザクション内で複数の独立したバーンメカニズムが順番にトリガーされることを避けてください。

BlockSecについて

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

BlockSecは、権威あるカンファレンスで複数のブロックチェーンセキュリティ論文を発表し、DeFiアプリケーションの複数のゼロデイ攻撃を報告し、1億ドル以上のハッキングを阻止し、数十億ドルの暗号通貨を保護してきました。

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

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

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

• 🔗 Phalconセキュリティアプリ: デモを予約

• 🔗 Phalconコンプライアンス