週刊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 Marketインシデント	価格操作	約239Kドル
2026/03/03	The V4 Router by z0r0zインシデント	ビジネスロジックの欠陥	約42Kドル
2026/03/05	The BitcoinReserveOffering Contractインシデント	ビジネスロジックの欠陥	約270万ドル
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にデプロイされたデフレTRC-20トークンプロトコルです。このプロトコルは、burnAndMintSwitchによって制御される定期的なデフレエンジンを組み込んでいます。所有者がsetBurnAndMintSwitch(true)を介して有効にすると、免除されない任意の転送が_update()フックをトリガーすると、最後のトリガー以降の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トークンがバーンされ、準備金には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ドルの損失が発生しました。根本原因は、Payment Managerコントラクトにおけるビジネスロジックの欠陥でした。ジョブの状態はストレージ参照ではなくメモリコピーとしてロードされたため、累積払い出しの追跡はオンチェーンに永続化されませんでした。これにより、攻撃者はジョブを作成し、フェーズ遷移中に自動支払いリリースをトリガーし、その後、許可されていないクレーム機能を通じて同じエスクロー資金を再度請求できるようになりました。

背景

ACP（Agent Commerce Protocol）は、クライアントとプロバイダーのインタラクションのために設計されたモジュラーオンチェーンコマースプロトコルです。アカウント、ジョブ、メモの3つのレイヤーでアクティビティを構造化します。ジョブは固定のライフサイクル（REQUEST → NEGOTIATION → TRANSACTION → EVALUATION → COMPLETED）に従い、支払いはTRANSACTIONフェーズ中にPaymentManagerコントラクトによってエスクローされます。ジョブがCOMPLETEDに達すると、プロトコルはreleasePayment()関数を介してプロバイダーにエスクローされた資金をリリースします。二重請求を防ぐために、プロトコルはジョブ構造体上の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 Marketインシデント

概要

2026年3月2日、Ethereum上のsDOLA Llamalend Marketが悪用され、約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 Market（0x2b08...4fbe）です。

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

背景で説明したように、get_x_down()は、2つの価格アンカー（動的、ライブオラクルと連動して移動するアンカー、および静的、ポジション作成時に固定されたアンカー）を介した往復変換をシミュレートすることによってヘルスを計算します。プロトコルは、 $P\\_{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つのローンは主に資金調達/決済レグであり、コアの悪用ステップ自体ではありません。

結論

このインシデントは、同じジョブライフサイクル内で担保価格操作攻撃によって引き起こされました。攻撃者はトランザクション内で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. The V4 Router by z0r0zインシデント

概要

2026年3月3日、Ethereum上のz0r0zのV4 Routerが悪用され、約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. The BitcoinReserveOffering Contractインシデント

概要

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

背景

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

脆弱性分析

根本原因は、mint()関数で完全なERC-3525``SFTデポジットを処理する際に、BitcoinReserveOfferingコントラクト（0x15f7...cfcf）がミントロジックを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残高を指数関数的にインフレさせ、過剰分をSolvBTCに償還することができました。

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

デポジット操作ごとに1回のみ資産会計が行われることを確認してください。
ミント額が基盤となるデポジット値を超えるのを防ぐために、不変チェックを追加してください。

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：攻撃者は、trueを返すようにハードコードされた単一のinitialized()関数を実装する最小限のコントラクトをデプロイしました。これはonlySpawnerTokenモディファイアチェックをパスするのに十分でした。
ステップ2：攻撃者のコントラクトは、同じ脆弱なonlySpawnerTokenモディファイアによって保護されているsetExemptFromSpawner()関数を呼び出し、攻撃者の署名アドレスを税金免除ホワイトリストに追加しました。これにより、その後の大規模なトークンダンピングがセルタックスや内部スワップロジックをトリガーせず、利益を最大化することが保証されました。
ステップ3：攻撃者はsetExemptFromSpawner() + mintFromSpawner()関数シーケンスをまずmEVMに対して、次に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をミントし、流動性を提供する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ドル）を利益としました。

結論

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

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

適切なアクセス制御、レート制限、またはクールダウン enforcementなしに、ペアからのバーン関数を公開しないでください。
単一のトランザクション内で複数の独立したバーンメカニズムが順番にトリガーされるのを避けてください。

BlockSecについて

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

BlockSecは、著名な会議で複数のブロックチェーンセキュリティ論文を発表し、DeFiアプリケーションの複数のゼロデイ攻撃を報告し、ハッキングをブロックして2000万ドル以上を救済し、数十億ドルの暗号通貨を確保しています。

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