Web3セキュリティインシデント週報 | 2026年3月23日～29日

過去1週間（2026/03/23 - 2026/03/29）、BlockSecは8件の攻撃インシデントを検出し分析しました。総推定損失額は約153万ドルです。以下の表にこれらのインシデントをまとめ、各ケースの詳細な分析を後続のセクションで提供します。

日付	インシデント	タイプ	推定損失額
2026/03/23	未知のインシデント1	整数オーバーフロー	~$97K
2026/03/23	未知のインシデント2	再入金（Reentrancy）	~$11K
2026/03/23	Cyrus Finance インシデント	ビジネスロジックの欠陥	~$512K
2026/03/23	BCE Token インシデント	トークン設計の欠陥	~$679K
2026/03/25	未知のインシデント3	会計エラー	~$1.2K
2026/03/25	MYX インシデント	ビジネスロジックの欠陥	~$3.6K
2026/03/26	未知のインシデント4	トークン設計の欠陥	~$133.5K
2026/03/27	EST Token インシデント	トークン設計の欠陥 & スポット価格への依存	~$92.3K

1. 未知のインシデント1

概要

2026年3月23日、イーサリアム上の検証されていないコントラクトが、その配布ロジックにおける整数オーバーフローにより、約97Kドルの損失を被りました。関数 0x317de4f6() は、オーバーフロー保護なしにユーザーが制御するトークン量を合計しており、攻撃者はラップアラウンドを引き起こし、わずか1 weiの USDT を支払うだけで claim() 関数を介してコントラクトの全 USDT 残高を引き出すことができました。

脆弱性分析

根本原因は、コントラクト 0xF0a105...568C97 の関数 0x317de4f6() における整数オーバーフローでした。この関数は、レコードの配列（それぞれアカウントと量を含む）を受け取り、配列を反復処理してすべての量を totalAmount に合計します。累積処理にオーバーフローチェックが欠けていたため、攻撃者は uint256 をラップアラウンドする量を持つように細工されたレコードを提供でき、個々の割り当てが大きいままで totalAmount を任意に小さくすることができました。

攻撃分析

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

ステップ1：攻撃者は、攻撃の初期資本としてUniswap V4から1 weiの USDT を調達しました。
ステップ2：攻撃者は、被害者コントラクトの USDT 残高を照会し、細工された配列を渡して 0x317de4f6() を呼び出しました。1つの量は uint256 の上限近くに設定され、もう1つは被害者コントラクトの USDT 残高に設定されました。それらの合計は1にオーバーフローし、攻撃者は被害者の全 USDT 残高に相当する割り当てを記録しながら、わずか1 weiの USDT のみを支払うことができました。
ステップ3：攻撃者は claim() を呼び出し、被害者コントラクトから97,812e6 USDT を引き出しました。
ステップ4：攻撃者はUniswap V4から借りた1 weiの USDT を返済し、残りの USDT を WETH に交換して、エクスプロイトを完了しました。

結論

このインシデントは、0.8.0より前のSolidityバージョンでチェックされていない算術演算を使用することのリスクを浮き彫りにしています。すべての重要な財務計算は、ラップアラウンド問題を回避するために、オーバーフロー安全な算術演算（例：SafeMathまたはSolidity >=0.8.x）を明示的に使用する必要があります。

2. 未知のインシデント2

概要

2026年3月23日、イーサリアム上の検証されていないコントラクトが、再入金（Reentrancy）の脆弱性により、約11Kドルの損失を被りました。関数 0xbe16634e() は、決済前に流動性関連の会計を更新し、再入金保護なしに外部コールバックを呼び出しました。前の呼び出しが決済される前に繰り返し関数に再入金することで、攻撃者は記録された流動性を膨張させ、後に実際に入金した量よりも多くの USDC と WETH を引き出しました。

脆弱性分析

根本原因は、コントラクト 0x39Ed37...9C6b08 の関数 0xbe16634e() における再入金の問題です。この関数は、決済前にユーザー流動性やティックリザーブなどの流動性関連の状態を更新し、再入金ガードなしに msg.sender.call() を介して外部コールバックを呼び出します。残高チェックは呼び出しごとに実行されるため、攻撃者は内部流動性会計を膨張させるために、関数に再帰的に再入金でき、最も深い呼び出しでの単一トークン転送でも、ネストされた実行フローを満たすのに十分でした。

攻撃分析

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

ステップ1：攻撃者は、攻撃の初期資本としてUniswap V4から100e8 USDC と 10e18 WETH を調達しました。
ステップ2：攻撃者は流動性追加のために 0xbe16634e() を呼び出しました。実行中、被害者コントラクトは攻撃者の関数 0x7c65be42() を呼び出し、これが前の呼び出しが決済される前に 0xbe16634e() に再入金しました。
ステップ3：この再入金フローを複数回繰り返すことで、攻撃者は記録された流動性を継続的に増加させました。最も深い呼び出しでは、攻撃者は必要なトークンを一度転送し、これがネストされた残高チェックを満たすのに十分でした。
ステップ4：記録された流動性を膨張させた後、攻撃者はプール状態を確認し、プールにさらに資金を転送したため、今後の引き出しをカバーするのに十分な USDC と WETH がプールに含まれていました。
ステップ5：攻撃者は流動性除去のために再度 0xbe16634e() を呼び出し、膨張した会計に基づいてプールから USDC と WETH を引き出しました。
ステップ6：攻撃者はUniswap V4を返済し、残りの USDC を WETH に交換して、エクスプロイトを完了しました。

結論

このインシデントは、決済前に流動性会計を更新し、保護されていない外部コールバックを呼び出すことの危険性を示しています。同様のエクスプロイトを防ぐために、プロトコルはチェック-効果-相互作用パターンを厳密に順守し、再入金ガードで外部コールバックを保護する必要があります。

3. Cyrus Finance インシデント

概要

2026年3月23日、BNB Chain上のイールドファーミングプロトコルであるCyrus Financeは、プールの現在のスポット価格に依存する不十分な流動性除去式により、約512Kドルの損失を被りました。プロトコルはCYRP NFTポジションをPancakeSwap V3流動性の比例シェアを表すものとして使用しますが、ユーザーシェアから基盤となる流動性への変換は slot0() を読み取ります。これは、同じトランザクション内で操作可能です。フラッシュローンで資金調達されたスワップにより価格をシフトさせることで、攻撃者はNFTポジションの流動性価値を膨張させ、公正な権利よりも多くのものを引き出しました。

背景

Cyrus FinanceはBNB Chain上のイールドファーミングプロトコルであり、PancakeSwap V3プールで流動性ポジションを管理しています。ユーザーは USDT を預け入れてCYRP NFTポジションを受け取ります。これは、複数のPancakeSwap V3ポジションにわたるプロトコルの流動性のシェアを表します。ユーザーは exit() 関数を介して元本と報酬を引き出すことができます。

脆弱性分析

脆弱性は、CyrusTreasury (0xb042Ea...0aE10b) の withdrawUSDTFromAny() 関数にあります。引き出しを処理する際、この関数はPancakeSwap V3プールから slot0() （つまり、現在のスポット価格）の sqrtPriceX96 を取得し、それを getAmountsForLiquidity() に渡して、プロトコルの全ポジション流動性が現在どれだけの amount0 / amount1 を表すかを推定します。

その後、そのスポット価格ベースの評価から availableUSDT を導出し、次の式を使用して、要求された引き出しのためにどれだけの流動性を使用すべきかを決定します。

$liquidityToUse = liquidity \cdot remaining / availableUSDT$

つまり、コントラクトは直接固定の所有権シェアを償還するわけではありません。代わりに、まずライブプール価格を使用してポジションの現在のUSDT相当価値を推定し、その後、要求された USDT 量を比例流動性量に逆変換します。

これは、slot0() が同じトランザクション内で操作可能であるため安全ではありません。プールの価格を一時的に移動させることで、攻撃者は availableUSDT を歪めることができ、これは計算された liquidityToUse に直接影響します。

攻撃分析

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

ステップ1：攻撃者は、PancakeSwap V3プールからフラッシュローンを開始し、約1,798 ETH を借入しました。
ステップ2：攻撃者は、ターゲットプールで大規模な ETH から USDT へのスワップを実行しました。ここではプロトコルが流動性ポジションを維持していましたが、意図的にプールの価格と現在のティックをシフトさせました。同時に、攻撃者はCYRP NFTポジション#15505を safeTransferFrom() を介して攻撃コントラクトに転送しました。
ステップ3：攻撃者は CyrusTreasury の exit(15505) を呼び出しました。実行中、withdrawUSDTFromAny() はPancakeSwap V3プールから slot0() を読み取り、操作されたスポット価格に基づいて availableUSDT を計算しました。歪んだティックのために、プロトコルはNFTシェアに対応する流動性価値を過大評価しました。次に decreaseLiquidity() と collect() を呼び出し、Cyrusポジションの公正価値を超える過剰な USDT を解放しました。
ステップ4：攻撃者はプールの状態を復元し、フラッシュローンを返済し、残りの利益（約512Kドル）をEOA 0xf96EB1...3b63b に転送しました。

結論

緩和策は、スポット slot0() 価格設定を、流動性を引き出し可能な USDT に変換する前に、操作耐性のある価格設定（十分な観測ウィンドウでのTWAP、またはChainlinkのような外部オラクル）に置き換えるべきです。

4. BCE Token インシデント

概要

2026年3月23日、BNB Chain上のPancakeSwap BCE-USDT プールは、BCE トークンの不十分なバーン（焼却）メカニズムにより、約679Kドルの損失を被りました。攻撃者は2つの悪意のあるコントラクトをデプロイして BCE の売買制限を回避し、流動性プールリザーブに対するトークンバーンをトリガーして、プールの価格を操作し、その USDT を流出させました。

脆弱性分析

脆弱性は、BCE トークン (0xcdb189...999999) の不十分なバーンメカニズムに由来します。根本的な問題は、ユーザーが影響を与える状態変数 scheduledDestruction が、ユーザー自身の残高からではなく、PancakeSwapペアアドレスから直接トークンをバーンするために使用されることです。売却操作中、コントラクトは取引量と現在のプールリザーブに基づいて scheduledDestruction に破壊量を蓄積します。この値は売り手から差し引かれません。代わりに、ペアからトークンをバーンし sync() を呼び出す別のコードパスを通じて後で実行されます。

攻撃者は取引量を制御し、プールリザーブを操作できるため、scheduledDestruction を任意の有効な値に設定し、ペアの BCE リザーブを圧縮するバーンをトリガーして、有利なようにプールの価格を歪めることができました。

攻撃分析

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

ステップ1：攻撃者は、複数のフラッシュローンと貸付プールを介して1億2350万 USDT を借入するために、悪意のあるコントラクト（MC1）を呼び出しました。
ステップ2：攻撃者は2番目の悪意のあるコントラクト（MC2）をデプロイし、借入したすべての USDT をMC2に転送しました。
ステップ3：攻撃者は（MC2を介して） BCE-USDT プールで222万 USDT を552.9万 BCE と交換しました。
ステップ4：攻撃者はMC2からMC1に552.9万 BCE を転送しました（MC1.drain() を介して）。バーンメカニズムのため、MC1は276.4万 BCE を受け取りました。
ステップ5：攻撃者は（MC1を介して）248.8万 BCE を136.8万 USDT と交換し、プールリザーブとスワップ量に基づいて scheduledDestruction 変数を約174Kに更新しました。この変数は後にバーン量として使用されました。
ステップ6：攻撃者は（MC2を介して）3490万 USDT を348.4万 BCE と交換し、BCE リザーブを約174Kにさらに操作しました。
ステップ7：攻撃者はMC2から残りの BCE と USDT をMC1に転送しました。scheduledDestruction が0より大きかった（約174K）ため、BCE の転送によりバーンがトリガーされ、BCE リザーブが約10,000に圧縮されました。
ステップ8：攻撃者は残りの BCE を操作された価格で USDT と交換しました。
ステップ9：攻撃者はすべてのローンを返済し、約679Kドルの利益を上げました。

結論

このインシデントは、ユーザーが影響を与える状態変数が、ユーザー自身の残高ではなく、流動性プールの残高を変更するために使用された、トークンの経済ロジックにおける根本的な欠陥によって引き起こされました。コントラクトは、取引活動から導出された破壊がユーザーコストを反映すると暗黙的に仮定していましたが、実際には、攻撃者が限定的な資本エクスポージャーで遅延バーンを構築し、流動性プロバイダーから価値を抽出することを可能にしました。その結果、攻撃者は限られた資本エクスポージャーでプール深度と価格設定を操作し、流動性プロバイダーから価値を抽出することができました。

5. 未知のインシデント3

概要

2026年3月25日、BNB Chain上の検証されていないステーキングコントラクトが、複数のステーキングモード間での不整合な会計により、約1.2Kドルの損失を被りました。コントラクトは、これらの関数が異なるトークンバスケットと比率を扱っていたにもかかわらず、stake2()/withdraw2() と stake3()/withdraw3() の間で同じポジション変数を共有していました。攻撃者はより軽量な stake2() モードで預け入れ、より重量な withdraw3() モードで償還し、繰り返し過剰なトークンを抽出しました。

背景

これは、いくつかのステーキングおよび引き出しモードを備えたステーキングコントラクトです。標準の stake() および withdraw() パスはフルステーキングモードであり、Pangolin、Bzzt、Bzzone のバスケットと報酬会計ロジックを一緒に処理します。 stake3() および withdraw3() パスは、同じ3トークンバスケットとデポジット/引き出し比率を使用しますが、追加の報酬会計フローをスキップします。対照的に、stake2() および withdraw2() パスは、Pangolin と Bzzt のみを扱う軽量モードであり、そのため他の2つのモードとは異なるトークン組み合わせと比率を使用します。

脆弱性分析

根本原因は、コントラクト 0x29d36c...774137 における不整合な会計でした。stake2()/withdraw2() と stake3()/withdraw3() は異なるトークンバスケットを扱っていましたが、すべて同じ変数 _exit[msg.sender] と _totalSupply を更新しました。その結果、より軽量な stake2() モードで作成されたポジションは、より重量な withdraw3() モードで償還される可能性がありました。

実際には、stake2(amount) は amount の Pangolin と amount の Bzzt のみを引き出しましたが、withdraw3(amount) は amount の Pangolin、10 * amount の Bzzt、そして 10 * amount の Bzzone を返しました。これは、20e18 Pangolin と 20e18 Bzzt を stake2() でステーキングすると、withdraw3() を介して償還できる _exit 残高が作成されることを意味しました。この不一致を繰り返すことで、攻撃者は継続的にコントラクトから過剰なトークンを抽出しました。

攻撃分析

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

ステップ1：攻撃者は、アドレス 0x9bce07d8bbe4f19dfe465710ff9612878bfe3302 にコントラクトをデプロイし、0.05 BNB で資金を調達し、資金を WBNB にラップし、正確に20e18 Pangolin、20e18 Bzzt、および200e18 Bzzone と交換し、ステーキングコントラクトに取得したトークンを使用する許可を与えました。
ステップ2：攻撃者は、入力として20e18を使用して stake2() を呼び出しました。これにより、20e18 Pangolin と 20e18 Bzzt がステーキングコントラクトに転送され、攻撃者の共有 _exit 残高が20e18増加しました。
ステップ3：攻撃者は次に、入力として20e18を使用して withdraw3() を呼び出しました。withdraw3() は共有 _exit 残高のみをチェックしたため、コントラクトはポジションが stake2() で作成されたにもかかわらず、20e18 Pangolin、200e18 Bzzt、および200e18 Bzzone を返しました。
ステップ4：攻撃者は、同じトランザクション内で stake2() -> withdraw3() のサイクルを何度も繰り返しました。各ラウンドで、返された Pangolin と返された Bzzt の一部が次の stake2() 呼び出しに使用され、Bzzone はステーキングコントラクトに戻されたため、後続の withdraw3() 呼び出しが継続して成功しました。このループを通じて、攻撃者は Bzzt 残高を20e18から16,400e18に増加させました。
ステップ5：攻撃者は取得したトークンを WBNB に交換し、資金を BNB にアンラップし、約2.007e18 BNB を攻撃者EOAに戻して、エクスプロイトを完了しました。

結論

同様のエクスプロイトを防ぐために、ステーキングコントラクトは各モードの会計を分離し、すべての引き出しパスが対応するデポジットパスの正確な資産構成と比率と一致することを確認する必要があります。

6. MYX インシデント

概要

2026年3月25日、MYX Networkの sMYX コントラクトがイーサリアム上でエクスプロイトされ、プールから約670万 MYX トークン（約3.6Kドルの利益）が流出しました。根本原因は、sMYX コントラクトにおける転送関数の供給会計と配当分配ロジックとの間の不十分な相互作用でした。制御下の口座間で sMYX を繰り返し転送することにより、攻撃者は1株あたりの利益（profit-per-share）変数を膨張させ、裏付けのない配当を偽造し、元々預け入れた量よりも多くの MYX を抽出しました。

背景

sMYX コントラクト (0x404328...d27F66) は配当分配トークンモデルに従っています。ユーザーは購入関数を介して MYX トークンを預け入れ、そのステーキングを表す sMYX シェアを受け取ります。配当は、stor_11 に格納されているグローバルアキュムレータ（profit-per-share）を使用して追跡されます。各ユーザーの請求可能な配当は、蓄積された利益の比例シェアと記録された支払いベースラインとの差として計算されます。このモデルは、初期の反射型トークンに似ており、流入する価値が既存の保有者に再分配されます。

脆弱性分析

脆弱性は、供給会計と配当分配ロジックとの間の不十分な相互作用から生じます。転送関数は、現在の総供給量で割った転送額に基づいてグローバルなprofit-per-share変数を増加させることで、新しい配当を誤って導入します。この操作は、実際の MYX トークンの流入によって裏付けられていないため、配当は実際のエコノミックアクティビティではなく、内部会計から効果的に作成されます。同時に、関数は、実際にはトークンがバーンされていないにもかかわらず、減算ヘルパーの逆の意味論により、記録された総供給量を転送額だけ減少させます。

結果として、転送額がますます小さい総供給量で割られるため、後続の各転送により profit-per-share 値が増加します。

攻撃分析

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

ステップ1：攻撃者は、フラッシュスワップを介して資本を調達し、それを MYX に変換しました。その後、sMYX コントラクトに預け入れて、配当システム内で支配的なシェアポジションを確保し、将来のほとんどの報酬分配を確実に制御しました。
ステップ2：攻撃者は、2つの制御されたコントラクトにポジションを分割し、配当実行と状態操作を交互に行う協調ループを開始し、脆弱な会計パスの繰り返し通過を可能にしました。
ステップ3：制御された口座間での繰り返し転送を通じて、攻撃者はプロトコルのprofit-per-share変数を人為的に膨張させ、同時に記録された総供給量を減少させ、裏付けのない配当を作成し、その分配率を増幅させました。
ステップ4：各操作サイクルの後に継続的に引き出すことで、攻撃者はこれらの偽造された報酬の大部分を抽出し、新しい資本を導入することなく、事実上プロトコルから MYX リザーブを流出させました。
ステップ5：攻撃者はすべてのポジションから出口し、抽出した MYX を WETH に交換し、フラッシュローンを返済し、残りの残高を利益として保持しました。

結論

このインシデントは、配当会計の実装における重大な欠陥であり、単なるポンジのような経済設計の結果ではありません。このような脆弱性を軽減するために、転送操作は総供給量に影響を与えたり、配当分配をトリガーしたりしてはならず、profit-per-shareの更新は実際の資産が導入された場合にのみ発生する必要があります。

7. 未知のインシデント4

概要

2026年3月26日、BNB Chain上の紹介報酬付き TUR ステーキングコントラクトが、約133.5Kドルの損失を被りました。Stake コントラクトは、単一トランザクション内で操作可能なライブAMMスポット価格を使用して預け入れ価値を計算しました。攻撃者はフラッシュローンを使用して TUR の価格を膨張させ、インフレウィンドウ中にステーキングし、自己制御の紹介アカウントを介して過剰な TUR 報酬を流出させました。

背景

Stake コントラクト (0x03D809...415Abe) は、紹介報酬付きの TUR ステーキングコントラクトです。ユーザーは最初に bind() を介してアップラインをバインドし、次に stake() を呼び出します。これは、ステーキングされた TUR をバーン（0xdead に送信）し、ユーザーに内部 power を付与します。これは、ユーザーが後でどれだけの TUR 報酬を請求できるかを決定する重みです。

power は固定比率で割り当てられません。代わりに、getPowerAmount() は、預け入れられた TUR を、2つのライブAMM価格、TUR/NOBEL と NOBEL/USDT をチェーンして、USDTに換算された値に変換します。これらは両方とも現在のペアリザーブから読み取られます。コントラクトはまた、_distributeRefPower() を介して、最初と2番目の紹介者にボーナスパワーを付与します。

脆弱性分析

根本原因は、Stake コントラクトにおける安全でないスポット価格依存性でした。各デポジットで、stake() は uValue = getPowerAmount(amount) を計算し、それを _power = _uValue * 100 に変換し、ステーカーの会計を更新し、次に _distributeRefPower() を呼び出して追加のパワーを紹介者に伝播させます。

具体的には、uValue は次のように計算されます。

$u V a l u e = g e t P o w e r A m o u n t (a m o u n t)$

ここで、getPowerAmount() は実質的に次のようになります。

$amount \times \text{TUR/NOBEL スポット価格} \times \text{NOBEL/USDT スポット価格}$

実装は、これらの価格を getReserves() を介して現在のペアリザーブから直接読み取るため、ステーキング評価は、操作耐性のあるオラクルまたはTWAPではなく、トランザクション内のスポット価格に完全に依存します。

これにより、攻撃者は一時的に TUR のオンチェーン評価をインフレさせ、操作されたウィンドウ中にステーキングし、誇張された uValue と power を受け取ることができます。紹介ロジックは損害を増幅させます。_distributeRefPower() は、ステーカーのパワーの20%を最初の紹介者に、5%を2番目の紹介者に付与しますが、これらの追加割り当ては、それらの紹介者の対応する rewardDebt 更新では補われていません。その結果、攻撃者が制御する紹介アカウントは、Stake コントラクトから不均衡な TUR 報酬をすぐに請求できます。

攻撃分析

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

ステップ1：攻撃者は、ListaDAOのMoolahコントラクトから1,900,000e18 USDT をフラッシュローンとして借入しました。
ステップ2：攻撃者は、借入した資本を使用して NOBEL-USDT および TUR-NOBEL プールを操作し、一時的に TUR のスポット評価を急上昇させました。
ステップ3：操作されたウィンドウ中に、攻撃者は7,770,707e18 TUR を Stake コントラクトにステーキングしました。トランザクションは、8,283,864e18という大幅にインフレした uValue と、対応する power の828,386,488e18を示す StakeEvent を発行しました。
ステップ4：攻撃者はすでに自己制御の紹介アカウントを手配していたため、_distributeRefPower() は操作されたステーキングから導出された追加の報酬パワーをそれらに付与しました。最初と2番目の紹介者は、期待される20%と5%の紹介割り当てを受け取りました。
ステップ5：ブーストされた紹介アカウントは、Stake コントラクトから TUR 報酬を請求しました。同じトランザクションで、Stake は15,238,941e18 TUR を 0xFd11...AcEaB に、3,809,924e18 TUR を 0x9007...E550B に転送しました。両方のアドレスは直ちに同じ金額を攻撃者に転送しました。4:1の支払い比率は、コントラクトの20%対5%の紹介パワー分割と一致します。
ステップ6：トランザクションには、claim() 実装が請求者に報酬を送信する前に3%の TUR 手数料を請求することと一致して、Stake からファンドウォレット 0xb302...89923 に流れる請求手数料も示されています。
ステップ7：増幅された TUR 報酬を抽出した後、攻撃者は収益を USDT に交換し、1,900,000 USDT のフラッシュローンを返済し、133,490e18 USDT を 0xEf67...4e5898 に利益として転送しました。

結論

このインシデントは、TUR トークン自体のLP配当会計によるものではなく、Stake コントラクトにおける操作可能な報酬評価モデルによって引き起こされました。ステーキングパワーと紹介報酬をライブAMMリザーブ比率に結びつけることで、コントラクトはフラッシュローンで資金調達された攻撃者が TUR のスポット価格をインフレさせ、過剰な報酬パワーを生成し、自己制御の紹介アカウントを介してステーキングコントラクトから TUR を流出させることを可能にしました。より安全な設計は、スポットリザーブ価格設定を操作耐性のあるオラクルまたは十分に長いTWAPに置き換え、紹介パワーの増加が報酬債務会計の整合性とペアになることを保証する必要があります。

8. EST Token インシデント

概要

2026年3月27日、BNB Chain上の BNBDeposit コントラクトが、BNBDeposit におけるスポット価格依存と EST トークンの不十分なバーン（焼却）メカニズムという2つの問題により、約92.3Kドルの損失を被りました。価格依存性により攻撃者は大量の EST を取得でき、不十分なバーンメカニズムにより攻撃者はサンドイッチスタイルの操作を介して EST-WBNB プールを流出させることができました。

脆弱性分析

インシデントの根本原因は二重です：

BNBDeposit コントラクト (0xE71547...d29A61) の onTokenReceived() 関数は、コントラクトの残高と EST のスポット価格に基づいてユーザーの請求可能額を計算しましたが、これらは両方とも操作が容易でした。
EST トークン (0xD4524B...498a91) は、攻撃者が直接 EST をプールに転送することで EST-WBNB プールで EST をバーンできる、不十分なバーンメカニズムを実装しました。

その結果、攻撃者は両方の脆弱性を利用してサンドイッチ攻撃を実行し、EST-WBNB プールから WBNB を窃取しました。

攻撃分析

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

ステップ1：攻撃者はMoolahを介して250,000e18 WBNB を借入し、攻撃のために15e18 WBNB を BNB にアンラップしました。
ステップ2：攻撃者は0.3e18 BNB を BNBDeposit に34回（合計10.2e18 BNB）繰り返し転送しました。各直接転送はデポジットロジックをトリガーしました。このステップで、攻撃者は約9,100e18 LPトークン（仮想会計）と2.65e18 WBNB をボーナスとして受け取りました。
ステップ3：攻撃者は400e18 WBNB を約822M EST と交換し、BNBDeposit を受信者として設定しました。これにより、BNBDeposit の EST 残高とプールの EST 価格の両方がインフレしました。
ステップ4：攻撃者は1e18 EST を BNBDeposit に転送して請求メカニズムをトリガーし、増幅された価格と残高に基づいて20M EST を受け取りました。
ステップ5：攻撃者は245,000e18 WBNB を約330M EST と交換し、BNBDeposit を受信者として設定しました。
ステップ6：攻撃者は約150回転送-スキムアクションを実行し、EST-WBNB プールで EST を継続的にバーンしました。
ステップ7：攻撃者は残りの EST を245,560e18 WBNB と交換しました。
ステップ8：攻撃者はフラッシュローンを返済し、150 WBNB の利益を上げました。

結論

このインシデントは、スポット価格依存性と不十分なバーンメカニズムという2つの問題によって引き起こされました。同様のリスクを軽減するために、プロジェクトはデプロイ前に信頼性の高い価格オラクルと健全なトークンバーンロジックを確保する必要があります。

BlockSecについて

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

BlockSecは、名高いカンファレンスで複数のブロックチェーンセキュリティ論文を発表し、DeFiアプリケーションのゼロデイ攻撃を複数報告し、多数のハッキングをブロックして2000万ドル以上を救済し、数十億ドルの暗号資産を保護しています。

公式ウェブサイト：https://blocksec.com/
公式Twitterアカウント：https://twitter.com/BlockSecTeam
🔗 BlockSec監査サービス : リクエストを送信
🔗 Phalcon Security APP：デモを予約
🔗 Phalcon Compliance