週刊Web3セキュリティインシデントまとめ | 2026年2月23日～3月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万ドル

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ルーターを介してUSDTをLAXOにスワップしました。取引制限（buyEnabled = false）と手数料ロジックを回避するため、攻撃者はBNB–LAXO V2ペアを作成し、そこを通じて取引をルーティングしました。

攻撃者は保有するすべてのLAXOをUSDT–LAXOペアに直接転送しました。これによりプール内のLAXO準備金が減少し、USDT準備金がほとんど変わらない状態で、USDT–LAXOペア内のLAXO価格が劇的に上昇しました。
攻撃者は操作された価格に基づき、burnAmount量のLAXOを約487,500e18のUSDTにスワップしました。
攻撃者はフラッシュローンを返済し、残りのUSDTを利益として保持しました。

結論

本インシデントの根本原因は、LAXOの欠陥あるバーンメカニズムにあります。これにより攻撃者は価格操作攻撃を行い、プールからUSDTを吸い上げることができました。その結果、合計約13.73万ドルの損失が発生しました。このような問題を緩和するため、プロジェクトは潜在的な価格操作攻撃を回避できるよう、バーンメカニズムの包括的なテストを実施する必要があります。

2. YieldBloxDAOインシデント

概要

2026年2月22日、StellarのBlend V2でYieldBlox DAOが運用するレンディングプールが攻撃を受け、1,000万ドルを超える損失が発生しました[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）を借りることが可能となりました。

攻撃分析

(Tx 1, 2) 攻撃者はSDEX上でUSTRY価格を操作し、1.06ドルから約107ドルまで引き上げました。SDEX上のUSTRY/USDC市場は非常に流動性が低かったため、攻撃者はすべての通常注文を消費した後に異常な注文を出し、市場価格を急激に押し上げました。

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

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

(Txs 8, 9, 10) 最後に、攻撃者は吸い上げた資産をBase、BSC、Ethereumなどの複数のチェーンにブリッジしました。

以下の表は、主な攻撃トランザクションと関連アドレスをまとめたものです。

ID	チェーン	アクション	被害額	Txハッシュ
1	Stellar	価格操作	-	09e1a9d1197c9bf0af4e87da328c4f2d5eb49b487630aa61991fb5c1c4637cdb
2	Stellar	価格操作	-	60fe039e96e88402d175c8de68e80651874ab125880dd384a1636914ba95bef1
3	Stellar	価格更新	-	56466ad66cd5c49a251b9f1c7c0cf6b1b2f62d121b58ff856e2b43673b22be51
4	Stellar	供給 1	-	b810ba4a8d7547bb024f17b58c32cc644533176206d0f8178d4ba0a545cb7597
5	Stellar	借入 1	100万ドル (100万USDC)	ae721cacee382bdecac8d2c47286ecd42cb4711f658bb2aec7cba60dc64a31ff
6	Stellar	供給 2	-	81f304ae627ba294df0f9c0708a58a2fe770b39d65f8cd0efe1d7d6d6cc885a6
7	Stellar	借入 2	985万ドル (6120万XLM)	3e81a3f7b6e17cc22d0a1f33e9dcf90e5664b125b9e61f108b8d2f082f2d4657
8	Stellar	BSCへブリッジ	-	1210ccb583c174e0ecb3cdc56adbc59a06d73b7ebcb07b7e9a1c0c371b9f00e3
9	Stellar	Baseチェーンへブリッジ	-	(最初)3fba5c384763349b74c7bfece148eb12600b161faf3382ba9c1f5f0fe76d52f5 (最後)df6129cce16edc7800a4199edb9d2ef2f3e6bfc9d3f44d6e29b3ab20c8dc1714 (合計15回)
10	Stellar	Ethereumチェーンへブリッジ	-	(最初)4012e2d140ea493de8d8abe5cc2ddd9e7d7f6661594d53fef5d0cfc26e1c7f0b (最後)f383fedb28dae42a6d8d8aab77de81d0645c67e57d3f6bc10683f659d229cce6 (合計16回)

結論

YieldBloxDAOインシデントでは多大な損失が発生しましたが、根本的な問題は複雑ではありません。担保評価が操作されやすい価格に依存しているということです。このインシデントは、レンディングプロトコルにおいて価格への依存先を慎重に選択し監視する必要があることを再認識させます。

参考文献

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

[2] https://reflector.network/

[3] SDEX上のUSTRY/USDC市場

3. STOインシデント

概要

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

背景

STOトークンはPancakeSwap V2プールを対象としたバーンメカニズムを導入しています。このメカニズムは、STOトークンの売却機能が有効（sellEnabled == true）かつpendingBurnFromSell > 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プロトコルが攻撃を受け、約1.57万ドルの損失が発生しました。根本原因はHedgePayプロトコルのステーキングコントラクトにおけるビジネスロジックの欠陥でした。具体的には、脆弱なステーキングコントラクト（0xBe189fe9f84cA531CD979630E1f14757b88dD80d）のforceExit()関数が、ユーザーのステーキング残高を更新することなく資産を引き出すことを可能にしていました。その結果、攻撃者はforceExit()関数を繰り返し呼び出すことで、コントラクトのHPAYトークンを吸い上げることができました。

背景

HedgePayプロトコルは、ユーザーがHPAYトークンをステーキングすることで報酬を獲得できるステーキングプロトコルです。forceExit()関数は、ユーザーがステーキングされた資産を引き出すためのものです。

脆弱性分析

インシデントの根本原因は、forceExit()関数のビジネスロジックにおける欠陥です。具体的には、ユーザーがstake()関数を介してHPAYトークンをステーキングすると、ステーキング額（_balances[msg.sender]）が適切に更新されます。しかし、ユーザーがforceExit()関数を介してステーキングしたHPAYトークンを引き出す際、コントラクトは_balances[msg.sender]を更新できていませんでした。その結果、攻撃者はforceExit()関数を繰り返し呼び出すことで、ステーキングコントラクト内のHPAYトークンを吸い上げることが可能でした。

攻撃分析

以下の分析はトランザクション 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プロトコルのプールが、オラクルの設定ミスにより約39万ドルの損失を被りました。具体的には、オラクルが誤って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価格フィードに設定されたことを確認しました。
攻撃者は即座にトランザクション（0xa17dc37e...705f8474）を送信しました。これにより、オラクルの設定ミスを利用して約8.8 USDCのみを担保にし、約187.3 ETHを借用することができました。
攻撃者はビルダーへの賄賂として約5.6 ETHを支払い、約181.7 ETHの利益を得ました。

結論

本インシデントの根本原因はオラクルの設定ミスであり、約39万ドルの損失をもたらしました。これは、オラクルの設定のような機密性の高い操作は、潜在的な損失を防ぐためにマルチシグウォレットやタイムロックで保護されるべきであるという教訓を与えています。

参考文献

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

6. FOOMCASHインシデント

概要

2026年2月26日、FOOMCASHプロトコルが脆弱なGroth16証明の検証[1]を悪用され、総額226万ドルを超える損失が発生しました。

背景

FOOMCASHプロトコルは、BaseおよびEthereum上の宝くじプロトコルで、引き出し検証にGroth16証明を使用しています。コントラクトFoomLotteryのcollect()関数は、WithdrawG16Verifier.verifyProof()関数を呼び出すことで、提供された証明（_pA、_pB、および_pC）を検証します。具体的には、検証はコントラクトWithdrawG16Verifier内の信頼された設定（つまりgammaとdelta）に基づいて実行されます。証明が有効であると検証されると、collect()関数はユーザーの入力（_recipientや_rewardbitsなど）に基づいて資産（FOOMトークン）の転送に進みます。

脆弱性分析

本インシデントの根本原因は、脆弱なGroth16の設定にありました。具体的には、コントラクトWithdrawG16Verifierにおいて、変数gamma（ $\gamma$ ）とdelta（ $\delta$ ）が同じ値（つまり $G_{2}$ ）を共有しており、攻撃者が任意の入力で有効な証明を偽造することができました。その結果、攻撃者はコントラクトWithdrawG16VerifierでのGroth16証明検証を回避し、悪意のある入力を用いてコントラクトFoomLottery内の全資産を吸い上げました。

攻撃分析

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

攻撃者は、有効な証明と悪意のある入力を構築するために悪意のあるコントラクトを作成しました。その悪意のあるコントラクトのフォールバックロジックにおいて：

有効な証明を構築しました。
有効な証明と悪意のある入力（_recipientや_rewardbitsなど）を用いて、コントラクトFoomLotteryのcollect()関数を呼び出しました。

a.collect()関数の呼び出しにおいて、証明検証（つまりWithdrawG16Verifier.verifyProof()）が回避され、資産（FOOMトークン）が攻撃者に転送されました。
ステップ1～2を30回繰り返し、合計19,695,576,757,802e18 FOOMトークンを吸い上げました。

結論

本インシデントの根本原因は、脆弱なGroth16検証設定にあり、結果として約226万ドルの損失が生じました。これは、複雑な暗号学的設定はデプロイ前に徹底的にレビュー・監査されなければならないことを強調しています。

参考文献

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

7. 不明なインシデント

概要

2026年2月27日、BNB Smart Chain上の不明なコントラクトが攻撃を受け[1]、約18万ドルの損失が発生しました。本インシデントの根本原因は不適切な入力バリデーションにありました。具体的には、被害を受けたコントラクトの _verifySignatures() 関数が空リストのチェックを行っておらず、攻撃者が署名や署名者を提供せずに署名検証を回避することができました。その結果、攻撃はこの脆弱性を利用して、被害者コントラクト内のすべての USDT トークンを吸い上げました。

脆弱性分析

本インシデントの根本原因は、署名検証フローにおける不適切なバリデーションです。具体的には、 _verifySignatures() 関数は allSigners.length == signatures.length であることのみをチェックしており、どちらの配列も空ではないことを必須としていませんでした。その結果、両方の配列が空のとき、攻撃者は署名検証を回避して資産を引き出すことができました。

攻撃分析

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

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

a.悪意のあるコントラクトは、意図された署名検証ロジックを回避して、allSigners と signatures に空の入力を渡して poolWithdraw() 関数を呼び出しました。

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

結論

本インシデントの根本原因は不適切な入力バリデーションであり、約18万ドルの損失をもたらしました。本インシデントは、入力に対する非空チェックのような基本的な境界チェックの重要性を強調しています。

参考文献

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

BlockSecについて

BlockSecは、フルスタックのブロックチェーンセキュリティおよび暗号資産コンプライアンスプロバイダーです。当社は、コード監査（スマートコントラクト、ブロックチェーン、ウォレットを含む）、リアルタイムでの攻撃阻止、インシデント分析、不正資金の追跡、およびAML/CFT義務への対応を、プロトコルおよびプラットフォームのあらゆるライフサイクルを通じて支援する製品やサービスを構築しています。

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

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