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

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

日付	インシデント	タイプ	推定損失額
2026/03/01*	BUBU2インシデント	トークン設計上の欠陥	約19.7Kドル
2026/03/02	ACPRouteインシデント	ビジネスロジックの欠陥	約58Kドル
2026/03/02	sDOLA Llamalendマーケットインシデント	価格操作	約239Kドル
2026/03/03	z0r0zによるV4ルーターインシデント	ビジネスロジックの欠陥	約42Kドル
2026/03/05	BitcoinReserveOfferingコントラクトインシデント	ビジネスロジックの欠陥	約2.7Mドル
2026/03/07	MoltEVMインシデント	ビジネスロジックの欠陥	約127Kドル
2026/03/08	LEDSインシデント	ビジネスロジックの欠陥	約64Kドル

*BUBU2インシデントは先週のレポートから漏れており、完全性を期すためにここに含めます。

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()実行後、プールから約1,025,988,664e18 BUBU2トークンがバーンされ、準備金には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フェーズ遷移がトリガーされ、プロバイダーコントラクトに全残高が自動的にリリースされるまで続きました。この時点で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}$ が変動すると、担保は、バンドを横断するアービトラージ主導のスワップ（ソフト清算）を通じて、徐々に担保トークンとcrvUSDの間で変換され、急激な清算をトリガーする代わりに、ポジションのリスクを徐々に軽減します。

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

脆弱性分析

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

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

背景で説明したように、get_x_down()は、2つの価格アンカー（動的、ライブオラクルと連動して変動するアンカー、および静的、ユーザーのバンド境界から導出されるアンカー）を介した往復変換をシミュレートすることによってヘルスを計算します。プロトコルは $P\\_{oracle}$ を読み取る際に遅延や健全性チェックを適用しません。したがって、オラクル価格が急騰すると、動的アンカーは上昇しますが、静的アンカーは変わりません。実際には、シミュレーションは急騰したオラクル価格でcrvUSDを担保に変換し、元のバンド価格で戻します。そのため、2つのアンカー間のギャップが広がるにつれて、評価された回復可能価値は縮小します。これにより、担保価格が上昇しても、ヘルスはゼロ未満になります。

攻撃分析

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

ステップ1：LLAMMAの状態（大規模スワップ）を操作してactive_bandを移動させ、多くのユーザーをxのみの姿勢（crvUSDのみ）に追い込みます。
ステップ2：寄付（donate()）を介して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つのローンは主に資金調達/決済レグであり、コアの悪用ステップ自体ではありません。

結論

このインシデントは、コラテラル価格操作攻撃です。攻撃者はインザトランザクションでsDOLA価格を操作し、LLAMMAのパスベースのヘルスメカニズムにより、ユーザーを清算状況に追い込みました。主な結果は、コラテラル価格が上昇してもポジションが清算可能になる可能性があることです。推奨される強化方向：

清算のために遅延またはTWAPコラテラル価格を使用してください。

参考文献

[1] Curve crvUSD LLAMMAドキュメント：[https://dev.curve.finance/crvUSD/amm/#bands](https://dev.curve.finance/crvUSD/amm/#bands)
[2] Curve LLAMMA清算説明：[https://dev.curve.finance/crvUSD/llamma-explainer/#liquidation](https://dev.curve.finance/crvUSD/llamma-explainer/#liquidation)
[3] Curveステーブルコインホワイトペーパー：[https://docs.curve.finance/pdf/whitepapers/whitepaper\_curve\_stablecoin.pdf](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()関数は、data（bytes）とdeadline（uint256）の2つのパラメータを受け取ります。関数内では、承認チェックがインラインアセンブリブロックを使用して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トークン残高を指数関数的に急増させ、その後、 excess を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()は安全にSFT全体をコントラクトに転送するためにERC3525TransferHelper.doSafeTransferIn()を呼び出します。これはonERC721Received()コールバックをトリガーします。このコールバック内では、コントラクトはすでにSFTの価値を計算し、送信者にBROをミントします。コールバックが返された後、mint()は実行を続行し、同じamount_を使用して価値を再計算し、2回目の_mint(msg.sender, value)操作を実行します。この二重ミント動作により、攻撃者はバーン・アンド・ミントループを通じてBRO残高を繰り返し急増させることができます。

攻撃分析

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

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

135e18 BROトークンをSFTトークンにラップします。
完全なSFT値でmint()を呼び出し、onERC721Received()コールバックをトリガーして135e18 BROトークンをミントします。外側のmint()はその後続行し、再度_mint()を呼び出し、合計270e18 BROトークンの二重ミントになります。
270e18 BROトークンをSFTトークンにラップし直します。

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

結論

このインシデントは、完全なSFTデポジット中の二重ミントによって引き起こされ、攻撃者は繰り返し行われるバーン・ミントサイクルを通じてBRO残高を指数関数的に急増させ、 excess を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を返すことを確認します。これらの条件は任意のコントラクトが同じインターフェースを実装することで容易に満たすことができるため、チェックは正当なスプワナートークンの意味のある認証を提供しません。

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

攻撃分析

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

ステップ1：攻撃者は、onlySpawnerTokenモディファイアチェックをパスするのに十分な、trueを返す単一のinitialized()関数を実装する最小限のコントラクトをデプロイしました。
ステップ2：攻撃者のコントラクトは、同じ脆弱なonlySpawnerTokenモディファイアによって保護されたsetExemptFromSpawner()関数を呼び出して、攻撃者のアドレスを税免除ホワイトリストに追加しました。これにより、その後の大規模なトークンダンプがセルタックスまたは内部スワップロジックをトリガーしないことが保証され、利益が最大化されました。
ステップ3：攻撃者は、mEVMに対してsetExemptFromSpawner() + mintFromSpawner()関数シーケンスを繰り返し実行し、その後CSPAWN、CCUTTL、LWORM、NHYDRAを含む複数のMoltling子トークンに対して実行しました。すべてのターゲットにわたってトークンをバッチミントし、それぞれの流動性プールにダンプして利益を抽出しました。

結論

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

今後同様のリスクを軽減するために：

特権ミントまたは設定関数に対する厳格なアクセス制御を強制してください。
承認のために容易に偽装可能なコントラクトチェックに依存しないでください。
明示的なホワイトリストまたは信頼できるコントラクトレジストリを通じて呼び出し者のIDを検証してください。

7. LEDSインシデント

概要

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

背景

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

脆弱性分析

根本原因は、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担保借入 + 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アプリケーションの複数のゼロデイ攻撃を報告し、ハッキングをブロックして2000万ドル以上を救済し、数十億ドルの暗号通貨を確保しました。

公式ウェブサイト: https://blocksec.com/
公式Twitterアカウント: https://twitter.com/BlockSecTeam
🔗 BlockSec監査サービス : リクエストを送信
🔗 Phalconセキュリティアプリ: デモを予約
🔗 Phalconコンプライアンス