週間Web3セキュリティインシデントまとめ｜2026年3月23日～29日

過去1週間（2026/03/23 - 2026/03/29）に、BlockSecは8件の攻撃インシデントを検出・分析しました。推定損失額の合計は約**$1.53M**です。以下の表に各インシデントの概要を示し、続く各節で詳細に分析します。

1. 不明なインシデント1

概要

2026年3月23日、Ethereum上の未検証コントラクトが、分配ロジックの整数オーバーフローを突かれ、約$97Kの被害を受けました。関数0x317de4f6()は、ユーザーが指定できるトークン数量をオーバーフロー対策なしで合計していました。攻撃者は値を一周させ、わずか1 weiのUSDTを支払うだけで、claim()関数を通じてコントラクトのUSDT残高全額を引き出しました。

脆弱性の分析

根本原因は、コントラクト0xF0a105...568C97の関数0x317de4f6()における整数オーバーフローでした。この関数は、アカウントと数量を含むレコードの配列を受け取り、配列を反復処理してすべての数量をtotalAmountに加算します。加算時にオーバーフローチェックがなかったため、攻撃者は合計がuint256の上限を超えて一周するようにレコードを細工できました。これにより、個々の割当額を大きく保ったまま、totalAmountを任意に小さくできました。

攻撃の分析

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

• ステップ1：攻撃者は、攻撃の初期資金としてUniswap V4から1 weiのUSDTを借りました。

  

• ステップ2：攻撃者は被害コントラクトのUSDT残高を照会し、細工した配列を指定して0x317de4f6()を呼び出しました。一方の数量をuint256の上限近くに、もう一方を被害コントラクトのUSDT残高に設定しました。合計がオーバーフローして1となったため、被害コントラクトのUSDT残高全額に相当する割当を記録しながら、支払いはわずか1 weiのUSDTで済みました。

  

• ステップ3：攻撃者はclaim()を呼び出し、被害コントラクトから97,812e6 USDTを引き出しました。

  

• ステップ4：攻撃者はUniswap V4から借りた1 weiのUSDTを返済し、残りのUSDTをWETHに交換して攻撃を完了しました。

結論

このインシデントは、Solidity 0.8.0より前のバージョンでチェックなしの算術演算を使用するリスクを示しています。値の一周を防ぐため、重要な金融計算には、オーバーフローに対して安全な算術演算（SafeMathやSolidity >=0.8.xなど）を明示的に使用すべきです。

2. 不明なインシデント2

概要

2026年3月23日、Ethereum上の未検証コントラクトがリエントランシーの脆弱性を突かれ、約$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の被害を受けました。このプロトコルは、PancakeSwap V3の流動性に対する比例持分をCYRP NFTポジションで表しますが、ユーザーの持分から基礎となる流動性への換算時に、同一トランザクション内で操作可能なslot0()を読み取っていました。攻撃者はフラッシュローンを資金源とするスワップで価格を動かし、自身のNFTポジションの流動性価値を水増しして、正当な持分を超える額を引き出しました。

背景

Cyrus Financeは、PancakeSwap V3プールの流動性ポジションを管理する、BNB Chain上のイールドファーミングプロトコルです。ユーザーはUSDTを預け入れ、複数のPancakeSwap V3ポジションにまたがるプロトコルの流動性に対する持分を表すCYRP NFTポジションを受け取ります。ユーザーは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に交換し、プール価格と現在のティックを意図的に動かしました。同時に、safeTransferFrom()を使ってCYRP NFTポジション#15505を0x01737d...6ffa3から攻撃コントラクトへ移しました。

• ステップ3：攻撃者はCyrusTreasuryのexit(15505)を呼び出しました。実行中、withdrawUSDTFromAny()はPancakeSwap V3プールからslot0()を読み取り、操作されたスポット価格に基づいてavailableUSDTを計算しました。歪められたティックにより、プロトコルはNFT持分に対応する流動性価値を過大評価しました。その後、decreaseLiquidity()とcollect()を呼び出し、Cyrusポジションの適正価値を超えるUSDTを払い出しました。

  

• ステップ4：攻撃者はプールの状態を元に戻してフラッシュローンを返済し、残りの利益（約$512K）をEOA 0xf96EB1...3b63bへ送金しました。

結論

対策として、流動性を引き出し可能なUSDTに換算する前に、slot0()に基づくスポット価格での評価を、価格操作に強い価格情報（十分な観測期間を設けたTWAPや、Chainlinkなどの外部オラクル）に基づく評価に置き換えるべきです。

4. BCEトークンのインシデント

概要

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：攻撃者は悪意あるコントラクト（MC1）を呼び出し、複数のフラッシュローンとレンディングプールを通じて123.5M USDTを借りました。

• ステップ2：攻撃者は2つ目の悪意あるコントラクト（MC2）をデプロイし、借りたUSDTをすべてMC2へ送金しました。

• ステップ3：攻撃者はMC2を通じて、BCE-USDTプールで2.222M USDTを5.529M BCEに交換しました。

• ステップ4：攻撃者はMC2からMC1へ、MC1.drain()を通じて5.529M BCEを送金しました。バーン機構により、MC1が受け取ったのは2.764M BCEでした。

• ステップ5：攻撃者はMC1を通じて2.488M BCEを1.368M USDTに交換し、プール準備金とスワップ数量に基づいて変数scheduledDestructionを約174Kに更新しました。この変数は後にバーン数量として使用されました。

• ステップ6：攻撃者はMC2を通じて34.9M USDTを3.484M BCEに交換し、BCE準備金を約174Kに近づけるようさらに操作しました。

• ステップ7：攻撃者はMC2からMC1へ、3.484M BCEと残りのUSDTを送金しました。scheduledDestructionが0を超えていたため（約174K）、BCEの送金によってバーンが発生し、BCE準備金は約10,000まで圧縮されました。

• ステップ8：攻撃者は操作された価格で、残りのBCEをUSDTに交換しました。

• ステップ9：攻撃者はすべての借入を返済し、約$679Kの純利益を得ました。

結論

このインシデントは、ユーザーの操作によって影響を受ける状態変数を使い、ユーザー自身の残高ではなく流動性プールの残高を変更するという、トークンの経済ロジックの根本的な欠陥が原因でした。コントラクトは、取引活動に由来するバーンがユーザーの負担を反映すると暗黙に想定していました。しかし実際には、攻撃者がLP準備金を対象に後から実行されるバーンを仕込めました。その結果、攻撃者は限られた自己資本リスクでプールの流動性の厚みと価格を操作し、流動性提供者から価値を奪えました。

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を払い戻します。つまり、stake2()で20e18 Pangolinと20e18 Bzztを預け入れると、後でwithdraw3()を通じて20e18 Pangolin、200e18 Bzzt、200e18 Bzzoneを引き出せる_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日、Ethereum上のMYX NetworkのsMYXコントラクトが悪用され、約667万MYXトークンがプールから流出しました（利益は約$3.6K）。根本原因は、sMYXコントラクトにおける送金関数の供給量計算と配当分配ロジックの欠陥のある相互作用でした。攻撃者は管理下のアカウント間でsMYXを繰り返し送金し、1シェア当たり利益の変数を水増しして、裏付けのない配当を作り出し、当初の預入額を超えるMYXを引き出しました。

背景

sMYXコントラクト（0x404328...d27F66）は、配当分配型のトークンモデルを採用しています。ユーザーは購入関数を通じてMYXトークンを預け入れ、持分を表すsMYXシェアを受け取ります。配当は、stor_11に保存されたグローバルな累積値（1シェア当たり利益）によって追跡されます。各ユーザーが請求できる配当は、累積利益に対する比例持分と、記録された支払い基準額との差として計算されます。このモデルは、流入した価値を既存の保有者に再分配する、初期のリフレクション型トークンに概念上似ています。

脆弱性の分析

脆弱性は、供給量計算と配当分配ロジックの欠陥のある相互作用から生じます。送金関数は、送金数量を現在の総供給量で割った値に基づいてグローバルな1シェア当たり利益の変数を増やし、誤って新たな配当を計上します。この処理には実際のMYXトークンの流入による裏付けがないため、配当は実際の経済活動ではなく内部の会計処理によって作り出されます。同時に、減算ヘルパーの意味が逆になっているため、実際にはトークンがバーンされていないにもかかわらず、記録上の総供給量が送金数量分だけ減少します。

その結果、後続の送金では、同じ送金数量をますます小さくなる総供給量で割るため、1シェア当たり利益の増加幅が大きくなります。

攻撃の分析

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

• ステップ1：攻撃者はフラッシュスワップで初期資金を調達してMYXに交換し、sMYXコントラクトに預け入れました。これにより配当システムで支配的な持分を取得し、将来の報酬分配の大部分を受け取れるようにしました。

• ステップ2：攻撃者はポジションを管理下の2つのコントラクトに分割し、配当の受け取りと状態の操作を交互に行う連携ループを開始しました。これにより、脆弱な会計処理の経路を繰り返し通過しました。

• ステップ3：管理下のアカウント間で送金を繰り返すことで、攻撃者はプロトコルの1シェア当たり利益の変数を人為的に水増しすると同時に、記録上の総供給量を減らしました。これにより裏付けのない配当を作り出し、その分配率を増幅しました。

• ステップ4：攻撃者は操作サイクルのたびに引き出しを続け、作り出した報酬の大部分を取得しました。新たな資金を投入せずに、プロトコルのMYX準備金を実質的に流出させました。

• ステップ5：攻撃者はすべてのポジションを解消し、引き出したMYXをWETHに交換してフラッシュローンを返済し、残額を利益として保持しました。

結論

このインシデントは、単にポンジスキームに似た経済設計の結果ではなく、配当会計処理の実装における重大な欠陥によるものです。この種の脆弱性を軽減するには、送金処理が総供給量に影響したり配当分配を発生させたりしないようにし、1シェア当たり利益の更新は実際の資産が流入した場合にのみ行う必要があります。

7. 不明なインシデント4

概要

2026年3月26日、BNB Chain上の紹介報酬付きTURステーキングコントラクトが悪用され、約$133.5Kの被害を受けました。Stakeコントラクトは、単一トランザクション内で操作可能なAMMの現在のスポット価格を使って預入価値を計算していました。攻撃者はフラッシュローンを使ってTURの価格をつり上げ、価格が高騰している間にステーキングし、自身が管理する紹介者アカウントを通じて過大なTUR報酬を引き出しました。

背景

Stakeコントラクト（0x03D809...415Abe）は、紹介報酬付きのTURステーキングコントラクトです。ユーザーはまずbind()で紹介元を紐付け、次にstake()を呼び出します。これによりステーキングしたTURがバーンされ（0xdeadに送られ）、後で請求できるTUR報酬の量を決める重みである内部的なpowerがユーザーに付与されます。

powerは固定比率で付与されるわけではありません。getPowerAmount()は、現在のペア準備金から読み取ったTUR/NOBELとNOBEL/USDTという2つのAMM価格を連鎖させ、預け入れたTURをUSDT建ての価値に換算します。また、コントラクトは_distributeRefPower()を通じて、1階層目と2階層目の紹介者にボーナスのpowerを付与します。

脆弱性の分析

根本原因は、Stakeコントラクトが安全でないスポット価格に依存していたことです。預入のたびに、stake()はuValue = getPowerAmount(amount)を計算し、それを_power = _uValue * 100に換算してステーキング利用者の会計値を更新した後、_distributeRefPower()を呼び出して上位の紹介者に追加のpowerを付与します。

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

$uValue = getPowerAmount(amount)$

ここで、getPowerAmount()は実質的に次の計算です。

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

実装はgetReserves()を通じて現在のペア準備金から価格を直接読み取るため、ステーキングの評価額は、価格操作に強いオラクルやTWAPではなく、同一トランザクション内のスポット価格に全面的に依存します。

これにより、攻撃者はTURのオンチェーン評価額を一時的につり上げ、操作された価格が有効な間にステーキングして、過大なuValueとpowerを受け取れます。紹介ロジックは被害を増幅します。_distributeRefPower()はステーキング利用者のpowerの20%を1階層目の紹介者に、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コントラクトにステーキングしました。トランザクションで発行されたStakeEventには、大幅に水増しされた8,283,864e18のuValueと、それに対応する828,386,488e18のpowerが記録されています。

• ステップ4：攻撃者は事前に自身が管理する紹介者アカウントを設定していたため、_distributeRefPower()は操作されたステーキングに由来する追加の報酬powerをそれらのアカウントに付与しました。1階層目と2階層目の紹介者には、想定どおり20%と5%の紹介者割当が付与されました。

• ステップ5：強化された紹介者アカウントは、StakeコントラクトからTUR報酬を請求しました。同一トランザクション内で、Stakeは15,238,941e18 TURを0xFd11...AcEaBへ、3,809,924e18 TURを0x9007...E550Bへ送金しました。両アドレスは直ちに同じ数量を攻撃者へ転送しました。支払額の4:1という比率は、コントラクトの紹介者powerの20%対5%という配分と一致します。

• ステップ6：トランザクションには、Stakeから資金用ウォレット0xb302...89923へ請求手数料が送られたことも記録されています。これは、報酬を請求者へ送る前に3%のTUR手数料を徴収するclaim()の実装と一致します。

• ステップ7：増幅されたTUR報酬を引き出した後、攻撃者は得た資金をUSDTに交換し、1,900,000 USDTのフラッシュローンを返済して、利益として133,490e18 USDTを0xEf67...4e5898へ送金しました。

結論

このインシデントの原因は、TURトークンの別個のLP配当会計処理ではなく、Stakeコントラクトの操作可能な報酬評価モデルでした。ステーキングpowerと紹介報酬を現在のAMM準備金比率に連動させたことで、攻撃者はフラッシュローンを資金源にTURのスポット価格をつり上げ、過大な報酬powerを作り出し、自身が管理する紹介者アカウントを通じてステーキングコントラクトからTURを引き出せました。より安全な設計では、現在の準備金に基づく価格設定を、価格操作に強いオラクルまたは十分に長い期間のTWAPに置き換え、紹介者のpowerを増やす場合には報酬債務の会計処理も整合的に更新すべきです。

8. ESTトークンのインシデント

概要

2026年3月27日、BNB Chain上のBNBDepositコントラクトが、BNBDepositのスポット価格への依存とESTトークンの欠陥のあるバーン機構という2つの問題を突かれ、約$92.3Kの被害を受けました。価格への依存により攻撃者は大量のESTを取得でき、欠陥のあるバーン機構により、サンドイッチ型の価格操作でEST-WBNBプールから資金を引き出せました。

脆弱性の分析

このインシデントの根本原因は2つあります。

1. BNBDepositコントラクト（0xE71547...d29A61）の関数onTokenReceived()は、コントラクトの残高とESTのスポット価格に基づいてユーザーの請求可能額を計算していました。どちらも容易に操作できます。

   

2. 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）。直接送金するたびに預入ロジックが発動しました。この段階で攻撃者は、仮想的な会計上のLPトークン約9,100e18と、ボーナスとして2.65e18 WBNBを受け取りました。

• ステップ3：攻撃者は400e18 WBNBを約822Me18 ESTに交換し、受取先をBNBDepositに設定しました。これにより、BNBDepositのEST残高とプール内のEST価格の両方をつり上げました。

• ステップ4：攻撃者は請求機構を発動させるため、1e18 ESTをBNBDepositへ送金しました。つり上げられた価格と残高に基づき、20Me18 ESTを受け取りました。

• ステップ5：攻撃者は245,000e18 WBNBを約330Me18 ESTに交換し、受取先をBNBDepositに設定しました。

• ステップ6：攻撃者は送金とスキムを組み合わせた操作を約150回行い、EST-WBNBプール内のESTを継続的にバーンしました。

• ステップ7：攻撃者は残りのESTを245,560e18 WBNBに交換しました。

• ステップ8：攻撃者はフラッシュローンを返済し、150 WBNBの純利益を得ました。

結論

このインシデントは、スポット価格への依存と欠陥のあるバーン機構という2つの問題が原因でした。同様のリスクを軽減するため、プロジェクトはデプロイ前に信頼できる価格オラクルと健全なトークンバーンロジックを確保する必要があります。

BlockSecについて

BlockSecは、ブロックチェーンセキュリティと暗号資産コンプライアンスを包括的に提供する企業です。プロトコルやプラットフォームのライフサイクル全体にわたり、コード監査（スマートコントラクト、ブロックチェーン、ウォレットを含む）、リアルタイムでの攻撃阻止、インシデント分析、不正資金の追跡、AML/CFT義務への対応を支援する製品とサービスを開発しています。

BlockSecは著名な学会で複数のブロックチェーンセキュリティ論文を発表し、DeFiアプリケーションに対する複数のゼロデイ攻撃を報告してきました。また、複数のハッキングを阻止して2,000万ドル以上の資金を救済し、数十億ドル相当の暗号資産を保護してきました。

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

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

• 🔗 BlockSec監査サービス : 依頼を送信

• 🔗 Phalcon Securityアプリ: デモを予約

• 🔗 Phalcon Compliance