過去1週間(2026年2月23日〜2026年3月1日)、BlockSecは7件の攻撃インシデントを検出し分析し、総損失額は約1300万ドルと推定されます。下の表はこれらのインシデントの概要を示しており、各ケースの詳細な分析は以下のサブセクションで提供されています。
| 日付 | インシデント | タイプ | 推定損失 |
|---|---|---|---|
| 2026/02/22 | LAXOインシデント | トークン設計上の欠陥 | ~$137K |
| 2026/02/22 | YieldBloxDAOインシデント | オラクルの誤設定 | ~$10M |
| 2026/02/23 | STOインシデント | トークン設計上の欠陥 | ~$16.1K |
| 2026/02/25 | HedgePayインシデント | ビジネスロジックの欠陥 | ~$15.7K |
| 2026/02/26 | Ploutosインシデント | オラクルの誤設定 | ~$390K |
| 2026/02/26 | FOOMCASHインシデント | ビジネスロジックの欠陥 | ~$2.26M |
| 2026/02/27 | 不明なインシデント | 不適切な入力検証 | ~$180K |
1. LAXOインシデント
概要
2026年2月22日、BNB Smart Chain上のERC20トークン「LAXO」がエクスプロイトされ、LAXO-USDTペアから約137,320ドルの損失が発生しました。根本原因は、LAXOがPancakeSwapペアに直接転送された際にトリガーされる、欠陥のあるバーン(焼却)メカニズムでした。ルーターはホワイトリストに登録されておりtransfer()内のバーンロジックをトリガーしないため、攻撃者はそれを回避しました。攻撃者はLAXOをペアに送信し、その後ペアの低レベルswap()を呼び出し、ペアトークンをバーンしてsync()を呼び出し、価格をインフレさせました。その後、攻撃者は利益を得るためにUSDTにスワップし直しました。
背景
LAXOトークンはバーンメカニズムを実装しています。転送の受取人がUSDT–LAXO PancakeSwapペアアドレスである場合、トークンはそれを売りとして扱い、ペアから対応する量のトークンをバーンしてからsync()を呼び出してペアの準備金を更新します。

さらに、LAXOトークンは、特定の(例えば、スワップルーターなどの)アドレスをバーンメカニズムと手数料から免除するためにホワイトリスト(_isExcludedFromFee)を実装しています。

脆弱性分析
インシデントの根本原因は、LAXOトークンのバーンメカニズムの欠陥でした。具体的には、LAXOをペアに直接転送するとバーンがトリガーされ、ペアからLAXOが削除され、その価格がインフレします。その結果、攻撃者はこれを利用して価格操作攻撃により利益を上げることができました。
攻撃分析
攻撃分析は、トランザクション 0xd58f3ef6...d98ac7d3 に基づいています。
-
攻撃者はPancakeSwap V3から350,000e18 USDTをフラッシュローンしました。
-
攻撃者はPancakeSwap Routerを介してUSDTをLAXOにスワップしました。取引制限(
buyEnabled = false)と手数料ロジックを回避するため、攻撃者はBNB–LAXO V2ペアを作成し、そこを経由して取引をルーティングしました。

-
攻撃者は保有するLAXOすべてをUSDT–LAXOペアに直接転送しました。これにより、USDT準備金はほぼ変更されませんでしたが、プール内のLAXO準備金が減少し、USDT–LAXOペアでのLAXOの価格が劇的に上昇しました。
-
攻撃者は操作された価格に基づき、
burnAmountのLAXOを約487,500e18 USDTとスワップしました。 -
攻撃者はフラッシュローンを返済し、残りのUSDTを利益として保持しました。
結論
このインシデントの根本原因は、LAXOのバーンメカニズムの欠陥であり、攻撃者は価格操作攻撃によりプールからUSDTを吸い上げることができました。その結果、インシデントによる総損失は約137.3Kドルでした。このような問題を軽減するために、プロジェクトは潜在的な価格操作攻撃を回避するために、バーンメカニズムの包括的なテストを実施する必要があります。
2. YieldBloxDAOインシデント
概要
2026年2月22日、StellarのBlend V2でYieldBlox DAOが運営するレンディングプールがエクスプロイトされ、1000万ドルを超える損失が発生しました[1]。このインシデントは、スマートコントラクトの脆弱性ではなく、プールオペレーター(YieldBlox DAO)による設定ミスが原因でした。
具体的には、攻撃者はSDEXのUSTRY/USDC市場を操作しました。プールに設定されたReflectorオラクルパスは、操作された価格を受け入れ、USTRYを担保として過大評価し、攻撃者がUSDCやXLMを含むプール資産を吸い上げることを可能にしました。
背景
Stellarブロックチェーンでは、Blend V2はユーザーが独立したレンディングプールを作成できる流動性プロトコルです。これらのプールは、サポートされている資産セット間でのユーザー間の貸付と借入を促進します。具体的には、このインシデントの被害プールでは、USTRYを担保としてXLMとUSDCを借りることができます。さらに、プール作成者は作成時にオラクルプロバイダーとしてReflectorオラクル[2]を指定します。Reflectorオラクルが提供するUSTRYの価格は、Stellar DEX(すなわちSDEX)のUSTRY/USDC市場に基づいて5分ごとに更新されます[3]。
脆弱性分析
根本原因は、SDEXの流動性の低いUSTRY/USDC市場における価格操作であり、ReflectorオラクルでのUSTRY価格の脆弱な更新につながりました。具体的には、USTRY/USDC市場の流動性が極めて低いため、攻撃者は通常の注文を消費し、異常な注文を出すことでUSTRY価格を100倍にインフレさせることができました。このインフレしたUSTRY価格はReflectorオラクルに伝播し、攻撃者は過大評価されたUSTRYを担保として、被害プールからすべての資産(すなわち、XLMとUSDC)を借り入れることができました。
攻撃分析
1.(Tx 1, 2)攻撃者はSDEXでUSTRYの価格を操作し、1.06ドルから約107ドルに押し上げました。SDEXのUSTRY/USDC市場の流動性は極めて低かったため、攻撃者はすべての通常の注文を消費し、異常な注文を出して市場価格を急激に引き上げました。


2.(Tx 3)Reflectorオラクルは、SDEXから操作された価格を取得し、それに応じて価格フィードを更新しました。

3.(Tx 4, 5)攻撃者は12,881e7 USTRYを担保に、1,000,196e7 USDCを借入しました。
4.(Tx 6, 7)攻撃者は14,987,610e7 USTRYを担保に、6,124,927,810e7 XLMを借入しました。

5.(Txs 8, 9, 10)最後に、攻撃者はBase、BSC、Ethereumを含む複数のチェーンに流出した資産をブリッジしました。
下の表は、主要なエクスプロイトトランザクションと関連するアドレスの概要を示しています。
結論
YieldBloxDAOインシデントは多額の損失をもたらしましたが、根本的な問題は複雑ではありません:担保評価は操作に脆弱な価格に依存しています。このインシデントは、レンディングプロトコルの価格依存性は慎重に選択・監視する必要があることを思い出させてくれます。
参考文献
[2] https://reflector.network/
[3] USTRY/USDC Market on the SDEX
3. STOインシデント
概要
2026年2月23日、BNB Smart ChainのPancakeSwap上のSTO-WBNBプールがドレインされ、約16.1Kドルの損失が発生しました。根本原因は、STOトークンのバーンメカニズムの欠陥でした。具体的には、ユーザーがプールでSTOトークンを売却すると、バーンメカニズムがトリガーされ、プールからSTOトークンがバーンされ、トークンの価格がインフレしました。その結果、攻撃者はこの脆弱性を利用して、プールからWBNBトークンをドレインしました。
背景
STOトークンは、PancakeSwap V2プールを対象としたバーンメカニズムを導入しています。このメカニズムは、STOトークンの売却機能が有効(すなわち、sellEnabled == true)であり、pendingBurnFromPrevSell > 0の場合にのみトリガーされます。ユーザーがSTOトークンを売却すると、メカニズムはプールからSTOトークンをバーンします。具体的には、バーンプロセス中に、前のトランザクションで売却されたSTOトークンの94%がバーンされます。
脆弱性分析
インシデントの根本原因は、STOトークンのバーンメカニズムの欠陥です。具体的には、ユーザーがSTOトークンを売却すると、バーンメカニズムはプールから一定量のSTOトークンを削除すると同時に、ペアコントラクトのsync()関数を呼び出して準備金を更新します。このバーンメカニズムは、プール内のSTOトークンの価格をインフレさせます。その結果、攻撃者は価格操作攻撃を実行することで、このメカニズムから利益を得ることができました。

攻撃分析
以下の分析は、トランザクション 0x8ba17bea...5a54020c に基づいています。
-
攻撃者はフラッシュローンにより360,894e18 WBNBを借入しました。
-
攻撃者は
initializeLiquidity()関数を呼び出し、STOトークンの売買機能を有効にしました。

-
攻撃者は360,894e18 WBNBを7,848,832e18 STOと交換しました。
-
攻撃者は
transfer()関数を呼び出し、バーンメカニズムをトリガーしてペアの準備金を操作しました(すなわち、STOトークンの価格を上昇させ)、同時に次のトランザクションでバーンされるSTOトークンの量を173,391e18に設定しました。

-
攻撃者は
swap()関数を呼び出し、STOをWBNBとスワップしました。このステップにより、攻撃者は操作された価格に基づいて利益を得ることができました。 -
攻撃者はステップ4と5を繰り返し、プールのWBNBをドレインしました。
-
攻撃者はフラッシュローンを返済し、26e18 WBNBの利益を確定しました。
結論
このインシデントの根本原因は、STOのバーンメカニズムの欠陥であり、攻撃者はプールからWBNBをドレインすることができました。このような問題を軽減するために、プロジェクトはシステム内に適切なアクセス制御を実装し、潜在的な価格操作攻撃を回避するために、バーンメカニズムの包括的なテストを実施する必要があります。
4. HedgePayインシデント
概要
2026年2月25日、BNB Smart Chain上のHedgePayプロトコルがエクスプロイトされ、約15.7Kドルの損失が発生しました。根本原因は、HedgePayプロトコルのステーキングコントラクトにおけるビジネスロジックの欠陥でした。具体的には、脆弱なステーキングコントラクト(すなわち、0xBe189fe9f84cA531CD979630E1f14757b88dD80d)のforceExit()関数により、ユーザーはステーキング残高を更新せずにステーキング資産を回収することができました。その結果、攻撃者はforceExit()関数を繰り返し呼び出すことで、コントラクトのHPAYトークンをドレインすることができました。
背景
HedgePayプロトコルは、ユーザーがHPAYトークンをステーキングすることで報酬を得ることができるステーキングプロトコルです。forceExit()関数は、ユーザーがステーキング資産を回収することを可能にします。
脆弱性分析
インシデントの根本原因は、forceExit()関数におけるビジネスロジックの欠陥です。具体的には、ユーザーがstake()関数を介してHPAYトークンをステーキングすると、ステーキング額(すなわち、_balances[msg.sender])がそれに応じて更新されます。しかし、ユーザーがforceExit()関数を介してステーキングされたHPAYトークンを回収する際、コントラクトは_balances[msg.sender]を更新しません。その結果、攻撃者はステーキングコントラクトのHPAYトークンを、forceExit()関数を繰り返し呼び出すことでドレインすることができました。

攻撃分析
以下の分析は、トランザクション 0x5f2ea6cb...46ed137f に基づいています。
-
攻撃者はフラッシュローンにより1,247,859e18 HPAYを借入しました。フラッシュローンコールバック関数内で:
a. 攻撃者は
stake()関数を介して1,197,944e18 HPAYをステーキングしました。b. 攻撃者は
forceExit()関数を繰り返し呼び出し、コントラクトのHPAYトークンをドレインしました。

- 攻撃者はフラッシュローンを返済し、57,389,615e18 HPAYを26e18 WBNBと交換しました(すなわち、26e18 WBNBを利益としました)。
結論
このインシデントの根本原因は、forceExit()関数がユーザーの_balances[msg.sender]を更新しなかったため、攻撃者がステーキングコントラクトのHPAYトークンをドレインできたことでした。このような問題を防ぐために、プロジェクトは状態不変条件が各関数で正しく維持されることを保証するために、適切な状態指向テストを実施すべきです。
5. Ploutosインシデント
概要
2026年2月26日、Ethereum上のPloutosプロトコールのプールが、オラクルの誤設定により約390,000ドルの損失を被りました。具体的には、オラクルがUSDCに対して誤ってBTC/USD Chainlink価格フィードを使用するように設定されていました。その結果、攻撃者はこの誤設定を利用して、わずか8 USDCの担保で187 ETHを借入しました。
脆弱性分析
Ploutosは、複数のネットワークに展開されているAave v3.0.2のフォークです。このインシデントは、レンディングプール(0xD060...F945D2)におけるオラクル設定の誤りが原因でした。

ブロック24538896で、USDCの価格オラクルは、USDC/USDフィードの代わりにBTC/USD Chainlinkフィードを参照するように誤って設定されました。次のブロック(24538897)で、攻撃者はこの誤設定を検出し、エクスプロイトを実行しました。その結果、攻撃者は約8.88 USDCを担保として、約187.3 ETHを利益として借入しました。

攻撃分析
-
攻撃者は、Ploutosプロトコルのオラクル設定操作を監視しており、Tx 0xcfedf6...bd193ab6 でUSDCのオラクルソースをChainlink BTC/USDC Price Feedに誤って設定しました。
-
攻撃者は即座にトランザクション(0xa17dc37e...705f8474)を送信し、オラクル誤設定により、約8.8 USDCを担保として約187.3 ETHを借入することを可能にしました。
-
攻撃者はビルダーへの賄賂として約5.6 ETHを支払い、約181.7 ETHを利益として得ました。
結論
このインシデントの根本原因はオラクルの誤設定であり、約390,000ドルの損失をもたらしました。これは、オラクル設定のような機密性の高い操作は、潜在的な損失を回避するためにマルチシグウォレットやタイムロックで保護されるべきであることを思い出させるものです。
参考文献
[1] https://x.com/Phalcon_xyz/status/2026943448734114011
6. FOOMCASHインシデント
概要
2026年2月26日、FOOMCASHプロトコルは脆弱なGroth16プルーフ検証[1]によりエクスプロイトされ、総損失額は2.26Mドルを超えました。
背景
FOOMCASHプロトコルは、BaseとEthereum上の宝くじプロトコルであり、引き出し検証にGroth16プルーフを使用しています。コントラクトFoomLotteryでは、collect()関数が、コントラクトWithdrawG16Verifier内の信頼されたセットアップ(すなわち、ガンマとデルタ)に基づいて、提供されたプルーフ(すなわち、_pA、_pB、および_pC)を検証するためにWithdrawG16Verifier.verifyProof()を呼び出します。プルーフが有効であると検証されると、collect()関数はユーザーの入力(例えば、_recipientと_rewardbits)に基づいて資産(すなわち、FOOMトークン)の転送に進みます。

脆弱性分析
インシデントの根本原因は、Groth16セットアップの脆弱性でした。具体的には、コントラクトWithdrawG16Verifierにおいて、変数ガンマ()とデルタ()が同じ値(すなわち、)を共有していたため、攻撃者は任意の入力で有効なプルーフを偽造することができました。その結果、攻撃者はコントラクトWithdrawG16VerifierにおけるGroth16プルーフ検証を回避し、悪意のある入力でコントラクトFoomLottery内のすべての資産をドレインしました。

攻撃分析
攻撃分析は、トランザクション 0xce204482...4e275e48 に基づいています。
攻撃者は、有効なプルーフと悪意のある入力を構築するための悪意のあるコントラクトを作成しました。悪意のあるコントラクトのフォールバックロジック内で:

-
有効なプルーフを構築しました。
-
有効なプルーフと悪意のある入力(例えば、
_recipientと_rewardbits)で、コントラクトFoomLotteryのcollect()関数を呼び出しました。
a. collect()関数の呼び出しにおいて、プルーフ検証(すなわち、WithdrawG16Verifier.verifyProof())は回避され、資産(すなわち、FOOMトークン)は攻撃者に転送されました。
- ステップ1〜2を30回繰り返し、合計で
19,695,576,757,802e18FOOMトークンをドレインしました。
結論
このインシデントの根本原因は、Groth16検証セットアップの脆弱性であり、2.26Mドルという損失をもたらしました。これは、複雑な暗号学的セットアップは、デプロイ前に徹底的にレビューおよび監査されなければならないことを強調しています。
参考文献
[1] https://x.com/Phalcon_xyz/status/2026941738141778394
7. 不明なインシデント
概要
2026年2月27日、BNB Smart Chain上の不明なコントラクトがエクスプロイトされ[1]、約180Kドルの損失が発生しました。このインシデントの根本原因は、不適切な入力検証でした。具体的には、被害コントラクトの_verifySignatures()関数は、空リストチェックを実行しなかったため、攻撃者は署名と署名者を提供せずに署名検証を回避することができました。その結果、攻撃者はこの脆弱性を利用して、被害コントラクト内のすべてのUSDTトークンをドレインしました。
脆弱性分析
このインシデントの根本原因は、署名検証フローにおける不適切な検証です。具体的には、_verifySignatures()関数はallSigners.length == signatures.lengthのみをチェックし、どちらの配列も空でないことを要求しません。その結果、両方の配列が空の場合、攻撃者は署名検証を回避して資産を引き出すことができます。


攻撃分析
以下の分析は、トランザクション 0x91f45260...41cfd784 に基づいています。
- 攻撃者は、自分の悪意のあるコントラクトの
0x2d0cb456()関数を呼び出しました。その呼び出しにおいて、
a. 悪意のあるコントラクトは、空の入力allSignersとsignaturesでpoolWithdraw()関数を呼び出し、意図された署名検証ロジックを回避しました。

b. 署名検証ロジックをバイパスした後、被害コントラクトはUSDTを攻撃者に転送しました。

結論
このインシデントの根本原因は、不適切な入力検証であり、約180Kドルの損失をもたらしました。このインシデントは、入力の空でないチェックなどの基本的な境界チェックの重要性を強調しています。
参考文献
[1] https://x.com/Phalcon_xyz/status/2027328894710505581
BlockSecについて
BlockSecは、フルスタックのブロックチェーンセキュリティおよび暗号コンプライアンスプロバイダーです。私たちは、顧客がコード監査(スマートコントラクト、ブロックチェーン、ウォレットを含む)、リアルタイムでの攻撃傍受、インシデント分析、不正資金追跡、およびAML/CFT義務の履行を、プロトコルおよびプラットフォームのライフサイクル全体にわたって実行できるよう支援する製品とサービスを構築しています。
BlockSecは、著名なカンファレンスで複数のブロックチェーンセキュリティ論文を発表し、いくつかのゼロデイ攻撃を報告し、複数のハッキングを阻止して2000万ドル以上を救済し、数十億ドル相当の暗号通貨を保護してきました。
-
公式ウェブサイト: https://blocksec.com/
-
公式Twitterアカウント: https://twitter.com/BlockSecTeam



