Web3セキュリティインシデント週次まとめ | 2026年2月23日~3月1日

Web3セキュリティインシデント週次まとめ | 2026年2月23日~3月1日

過去1週間(2026年2月23日~2026年3月1日)、BlockSecは7件の攻撃インシデントを検出し分析しました。総損失額は約1300万ドルと推定されます。以下の表にこれらのインシデントをまとめ、各ケースの詳細な分析は後続のセクションで提供します。

日付 インシデント タイプ 推定損失額
2026/02/22 LAXOインシデント トークン設計上の欠陥 約13.7万ドル
2026/02/22 YieldBloxDAOインシデント オラクルの誤設定 約1000万ドル
2026/02/23 STOインシデント トークン設計上の欠陥 約1.61万ドル
2026/02/25 HedgePayインシデント ビジネスロジックの欠陥 約1.57万ドル
2026/02/26 Ploutosインシデント オラクルの誤設定 約39万ドル
2026/02/26 FOOMCASHインシデント ビジネスロジックの欠陥 約226万ドル
2026/02/27 不明なインシデント 不適切な入力検証 約18万ドル

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() を呼び出してペアの準備金を更新します。 1.png さらに、LAXO トークンは、一部のアドレス(例:スワップルーター)をバーンメカニズムや手数料から除外するためのホワイトリスト(_isExcludedFromFee)を実装しています。 2.png

脆弱性分析

インシデントの根本原因は、LAXO トークンのバーンメカニズムの欠陥でした。具体的には、LAXO をペアに直接転送するとバーンがトリガーされ、ペアから LAXO が削除され、その価格がインフレします。その結果、攻撃者はこれを悪用して価格操作攻撃により利益を得ることができます。

攻撃分析

攻撃分析は、トランザクション 0xd58f3ef6...d98ac7d3 に基づいています。

  1. 攻撃者はPancakeSwap V3から350,000e18 USDT をフラッシュローンしました。

  2. 攻撃者はPancakeSwap Routerを介して USDTLAXO にスワップしました。取引制限(buyEnabled = false)と手数料ロジックを回避するため、攻撃者はBNB–LAXO V2ペアを作成し、そこを通して取引をルーティングしました。 3.png

  3. 攻撃者は保有するすべての LAXO をUSDT–LAXOペアに直接転送しました。これにより、プール内の LAXO 準備金が減少し、USDT 準備金はほぼ変更されなかったため、USDT–LAXOペアにおける LAXO の価格が劇的に上昇しました。

  4. 攻撃者は操作された価格に基づき、burnAmountLAXO を約487,500e18 USDT とスワップしました。

  5. 攻撃者はフラッシュローンを返済し、残りの USDT を利益として保持しました。

結論

このインシデントの根本原因は LAXO のバーンメカニズムの欠陥であり、攻撃者は価格操作攻撃を通じてプールから USDT を引き出すことができます。その結果、インシデントによる総損失額は約137.3Kドルとなりました。このような問題に対処するため、プロジェクトは潜在的な価格操作攻撃を回避するために、バーンメカニズムの包括的なテストを実施する必要があります。

YieldBloxDAOインシデント

概要

2026年2月22日、StellarのBlend V2でYieldBlox DAOが運営する貸付プールが悪用され、1000万ドルを超える損失が発生しました [1]。このインシデントは、スマートコントラクトの脆弱性ではなく、プールオペレーター(YieldBlox DAO)による設定ミスが原因でした。

具体的には、攻撃者はUSTRY/USDC市場をSDEXで操作しました。プールの設定されたReflectorオラクルパスは操作された価格を受け入れ、USTRYを過大評価し、攻撃者がUSDCやXLMを含むプール資産を引き出すことを可能にしました。

背景

Stellarブロックチェーンでは、Blend V2はユーザーが分離された貸付プールを作成できる流動性プロトコルです。これらのプールは、サポートされている一連の資産間でユーザー間の貸付と借入を促進します。具体的には、このインシデントの被害プールでは、USTRY を担保として XLMUSDC を借りることができます。さらに、プール作成者は作成時にオラクルプロバイダーとしてReflectorオラクル [2] を指定します。Reflectorオラクルが提供する USTRY の価格は、Stellar DEX(すなわちSDEX)の USTRY/USDC 市場に基づいて5分ごとに更新されます [3]。

脆弱性分析

根本原因は、SDEXの流動性の低い USTRY/USDC 市場での価格操作であり、これにより USTRY 価格がReflectorオラクルで脆弱な更新を引き起こしました。具体的には、USTRY/USDC 市場の流動性が非常に低いため、攻撃者は通常の注文を消費し、異常な注文を出すことで USTRY 価格を100倍にインフレさせることができました。このインフレした USTRY 価格はReflectorオラクルに伝播され、攻撃者は過大評価された USTRY を担保として被害プールからすべての資産(すなわち XLM および USDC)を借り入れることができました。

攻撃分析

1.(Tx 1, 2)攻撃者はSDEXで USTRY 価格を操作し、1.06ドル から約 107ドル に押し上げました。SDEXの USTRY/USDC 市場は流動性が非常に低かったため、攻撃者はすべての通常注文を消費し、異常な注文を出して市場価格を急激に上昇させました。 4.png 5.png 2.(Tx 3)Reflectorオラクルは操作された価格をSDEXから取得し、それに応じて価格フィードを更新しました。 6.png 3.(Tx 4, 5)攻撃者は 12,881e7 USTRY を担保として、1,000,196e7 USDC を借入しました。 7.png 4.(Tx 6, 7)攻撃者は 14,987,610e7 USTRY を担保として、6,124,927,810e7 XLM を借入しました。 8.png 5.(Txs 8, 9, 10)最後に、攻撃者はドレインした資産をBase、BSC、Ethereumを含む複数のチェーンにブリッジしました。

以下の表は、主要なエクスプロイトトランザクションと関連するアドレスをまとめたものです。

結論

YieldBloxDAOインシデントは大幅な損失をもたらしましたが、根本的な問題は複雑ではありません:担保評価額は操作の影響を受けやすい価格に依存しています。このインシデントは、貸付プロトコルの価格依存性は慎重に選択され、監視される必要があることを思い出させます。

参考文献

[1] https://blocksec.com/blog/yieldblox-dao-incident-on-stellar-oracle-misconfiguration-enabled-a-10m-drain

[2] https://reflector.network/

[3] USTRY/USDC Market on the SDEX

STOインシデント

概要

2026年2月23日、BNB Smart ChainのPancakeSwap上のSTO-WBNBプールがドレインされ、約16.1Kドルの損失が発生しました。根本原因は STO トークンのバーンメカニズムの欠陥でした。具体的には、ユーザーがプールで STO トークンを売却すると、バーンメカニズムがトリガーされ、プールから STO トークンがバーンされ、トークンの価格がインフレしました。その結果、攻撃者はこの脆弱性を悪用してプールから WBNB トークンをドレインしました。

背景

STO トークンはPancakeSwap V2プールを対象としたバーンメカニズムを導入しています。このメカニズムは、STO トークンの売却機能が有効(つまり sellEnabled == true)であり、pendingBurnFromSell > 0 の場合にのみトリガーされます。ユーザーが STO トークンを売却すると、メカニズムはプールから STO トークンをバーンします。具体的には、前回のトランザクションで売却された STO トークンの94%がバーンプロセス中にバーンされます。

脆弱性分析

インシデントの根本原因は、STO トークンのバーンメカニズムの欠陥です。具体的には、ユーザーが STO トークンを売却すると、バーンメカニズムはプールから一定量の STO トークンを削除すると同時に、ペアコントラクトの sync() 関数を呼び出して準備金を更新します。このバーンメカニズムは、プール内の STO トークンの価格をインフレさせます。その結果、攻撃者は価格操作攻撃を実行することで、このメカニズムから利益を得ることができます。 9.png

攻撃分析

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

  1. 攻撃者はフラッシュローンにより 360,894e18 WBNB を借入しました。

  2. 攻撃者は initializeLiquidity() 関数を呼び出し、STO トークンの売買機能を有効にしました。 10.png

  3. 攻撃者は 360,894e18 WBNB7,848,832e18 STO と交換しました。

  4. 攻撃者は transfer() 関数を呼び出し、ペアの準備金を操作するバーンメカニズムをトリガーし(つまり STO トークンの価格を上昇させ)、次のトランザクションでバーンされる STO トークンの量を 173,391e18 に設定しました。 11.png

  5. 攻撃者は swap() 関数を呼び出し、STOWBNB にスワップしました。このステップにより、攻撃者は操作された価格に基づいて利益を得ることができました。

  6. 攻撃者はステップ4と5を繰り返し、プールの WBNB をドレインしました。

  7. 攻撃者はフラッシュローンを返済し、26e18 WBNB の利益を確定しました。

結論

このインシデントの根本原因は STO のバーンメカニズムの欠陥であり、攻撃者はプールから WBNB をドレインすることができます。このような問題に対処するため、プロジェクトはシステム内に適切なアクセス制御を実装し、潜在的な価格操作攻撃を回避するためにバーンメカニズムの包括的なテストを実施する必要があります。

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] を更新しません。その結果、攻撃者は forceExit() 関数を繰り返し呼び出すことで、ステーキングコントラクトのHPAYトークンをドレインすることができます。 12.png

攻撃分析

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

  1. 攻撃者はフラッシュローンにより 1,247,859e18 HPAY を借入しました。フラッシュローンコールバック関数内で:

    a.攻撃者は stake() 関数を通じて 1,197,944e18 HPAY をステーキングしました。

    b.攻撃者は forceExit() 関数を繰り返し呼び出し、コントラクトのHPAYトークンをドレインしました。 13.png

  2. 攻撃者はフラッシュローンを返済し、57,389,615e18 HPAY26e18 WBNB とスワップし(すなわち、26e18 WBNB の利益を得ました)。

結論

このインシデントの根本原因は、forceExit() 関数がユーザーの _balances[msg.sender] を更新しなかったことで、攻撃者がステーキングコントラクトのHPAYトークンをドレインすることを可能にしたことです。このような問題を防ぐため、プロジェクトは状態不変条件が各関数で正しく維持されていることを確認するために、適切な状態指向テストを実施すべきです。

Ploutosインシデント

概要

2026年2月26日、Ethereum上のPloutosプロトコールのプールが、オラクルの誤設定により約390,000ドルの損失を被りました。具体的には、オラクルは USDC のためにBTC/USD Chainlink価格フィードを使用するように誤って設定されていました。その結果、攻撃者はこの誤設定を悪用し、わずか8 USDC を担保に187 ETH を借入しました。

脆弱性分析

Ploutosは、複数のネットワークにデプロイされているAave v3.0.2のフォークです。このインシデントは、貸付プール(0xD060...F945D2)におけるオラクルの誤設定が原因でした。 14.png ブロック24538896で、USDC の価格オラクルは、USDC/USDフィードの代わりにBTC/USD Chainlinkフィードを参照するように誤設定されました。次のブロック(24538897)で、攻撃者は誤設定を検出し、エクスプロイトを実行しました。その結果、攻撃者は約8.88 USDC を担保に、約187.3 ETH を利益として借入しました。 15.png

攻撃分析

  1. 攻撃者はPloutosプロトコルのオラクル設定操作を監視しており、Tx 0xcfedf6...bd193ab6USDC のオラクルソースをChainlink BTC/USDC Price Feedに誤って設定しました。

  2. 攻撃者は直ちにトランザクション(0xa17dc37e...705f8474)を送信し、オラクルの誤設定により、約8.8 USDC を担保に約187.3 ETH を借入することができました。

  3. 攻撃者はビルダーへの賄賂として約5.6 ETH を支払い、約181.7 ETH の利益を得ました。

結論

このインシデントの根本原因はオラクルの誤設定であり、約390,000ドルの損失をもたらしました。これは、オラクル設定などの機密性の高い操作は、潜在的な損失を回避するためにマルチシグウォレットまたはタイムロックで保護されるべきであることを思い出させるものです。

参考文献

[1] https://x.com/Phalcon_xyz/status/2026943448734114011

FOOMCASHインシデント

概要

2026年2月26日、FOOMCASHプロトコルが脆弱なGroth16プルーフ検証 [1] により悪用され、総損失額は226万ドルを超えました。

背景

FOOMCASHプロトコルは、BaseとEthereum上の宝くじプロトコルであり、引き出し検証のためにGroth16プルーフを使用しています。コントラクト FoomLotterycollect() 関数は、WithdrawG16Verifier.verifyProof() 関数を呼び出すことで、提供されたプルーフ(すなわち _pA_pB_pC)を検証します。具体的には、検証はコントラクト WithdrawG16Verifier 内の信頼されたセットアップ(すなわちガンマとデルタ)に基づいて行われます。プルーフが有効と検証された後、collect() 関数はユーザーの入力(例えば _recipient_rewardbits)に基づいて資産(すなわち FOOM トークン)を転送します。 16.png

脆弱性分析

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

攻撃分析

攻撃分析は、トランザクション 0xce204482...4e275e48 に基づいています。

攻撃者は悪意のあるコントラクトを作成し、有効なプルーフと悪意のある入力を構築しました。悪意のあるコントラクトのフォールバックロジック内で: 18.png

  1. 有効なプルーフを構築しました。

  2. 有効なプルーフと悪意のある入力(例えば _recipient_rewardbits)で FoomLottery コントラクトの collect() 関数を呼び出しました。

    1. collect() 関数の呼び出しにおいて、プルーフ検証(すなわち WithdrawG16Verifier.verifyProof())が回避され、資産(すなわち FOOM トークン)が攻撃者に転送されました。
  3. ステップ1-2を30回繰り返し、合計 19,695,576,757,802e18 FOOM トークンをドレインしました。

結論

インシデントの根本原因はGroth16検証セットアップの脆弱性であり、約226万ドルの損失をもたらしました。これは、複雑な暗号学的セットアップはデプロイ前に徹底的にレビューされ、監査される必要があることを強調しています。

参考文献

[1] https://x.com/Phalcon_xyz/status/2026941738141778394

不明なインシデント

概要

2026年2月27日、BNB Smart Chain上の不明なコントラクトが悪用され [1]、約180Kドルの損失が発生しました。このインシデントの根本原因は、不適切な入力検証でした。具体的には、被害コントラクトの _verifySignatures() 関数は空リストチェックを実行せず、攻撃者が署名と署名者を提供せずに署名検証を回避することを可能にしました。その結果、攻撃者はこの脆弱性を悪用して、被害コントラクト内のすべての USDT トークンをドレインしました。

脆弱性分析

このインシデントの根本原因は、署名検証フローにおける不適切な検証です。具体的には、_verifySignatures() 関数は allSigners.length == signatures.length のみをチェックし、いずれかの配列が空でないことを要求しません。その結果、両方の配列が空の場合、攻撃者は署名検証を回避して資産を引き出すことができます。 19.png 20.png

攻撃分析

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

  1. 攻撃者は自身の悪意のあるコントラクトの 0x2d0cb456() 関数を呼び出しました。呼び出しにおいて、

    a.悪意のあるコントラクトは、空の入力 allSignerssignaturespoolWithdraw() 関数を呼び出し、意図された署名検証ロジックを回避しました。 21.png b.署名検証ロジックをバイパスした後、被害コントラクトは USDT を攻撃者に転送しました。 22.png

結論

このインシデントの根本原因は不適切な入力検証であり、約180Kドルの損失につながりました。このインシデントは、入力に対する空リストチェックのような基本的な境界チェックの重要性を強調しています。

参考文献

[1] https://x.com/Phalcon_xyz/status/2027328894710505581

Sign up for the latest updates