Web3セキュリティインシデント週次まとめ | 2026年2月9日～2月15日

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

1. 未知のインシデント

概要

2026年2月10日、BNB Smart Chain上のコントラクト0x560d39が悪用され、推定損失額約1万ドルが発生しました。根本原因は、関数0xb1a87f2c()における不備のあるビジネスロジックであり、これにより流動性追加プロセスがサンドイッチ攻撃に対して脆弱になりました。

背景

コントラクト0x560d39では、関数0xb1a87f2c()は、入力パラメータに基づいてユーザーから対応する量のUSDTを転送します。受信したUSDTは処理され、その合計の**85%**が後続の流動性操作に割り当てられます。

この85%の部分から、半分がPancakeSwapプールを通じてAFXと交換され、取得したAFXはコントラクト0x671ce4に転送されます。その後、関数は0x671ce4からAFXを引き出します。

次に、PancakeSwap V2 Routerを介して、85%のUSDTの残りの半分と0x671ce4から引き出されたAFXを使用して、USDT-AFX取引ペアに流動性が追加されます。残ったUSDTまたはAFXはユーザーに返金されます。

USDT-AFX流動性追加が完了した後、関数はアドレス0x146933から追加のAFXを取得します。0x146933から取得した量は、以前に0x671ce4から引き出したAFXの量と等しく設定されます。関数は、PancakeSwap V2 AFX-AHTプール内の現在の価格比に基づいて必要なAHT量を計算し、0x146933から取得したAFXと計算されたAHTを使用して、AFX-AHT取引ペアに流動性を追加します。

脆弱性分析

脆弱なコントラクトは0x560d39です。コントラクト0x146933は、AFX-AHT流動性追加に使用されるAFXの資金源として機能し、最終的に損失を負担します。

根本原因は、0x560d39の関数0xb1a87f2c()における不備のあるビジネスロジックにあります。コントラクト0x671ce4を通じてUSDTを交換して取得したAFXを取得する際、関数は交換の前後に0x671ce4のAFX残高の変化を確認しません。代わりに、0x671ce4が保有するすべてのAFXを引き出します。

これにより、攻撃者は事前に0x671ce4に大量のAFXを寄付し、少量のUSDTのみで0xb1a87f2c()を呼び出すことができます。0x146933から取得するAFXの量が0x671ce4から引き出すAFXと一致するように定義されているため、0x671ce4からの引き出しを膨張させると、0x146933はAFX-AHT流動性追加に過剰な量のAFXを拠出することを直接強制されます。

攻撃者は、0x560d39からの残りのUSDTとAFXの返金を通じて寄付を回収でき、その間0x146933は過剰な流動性提供のコストを吸収します。

その後、攻撃者はAFX-AHT流動性追加をサンドイッチ攻撃することで利益を得ます。AFXからAHTへのスワップでフロントランし、被害者のトランザクションの周りでAHTからAFXへのスワップでバックランします。

攻撃分析

攻撃トランザクションの主要なステップは以下の通りです。

• ステップ1：攻撃者はPancakeSwap V2で1,130,500e18 AFXトークンをフラッシュローンしました。

• ステップ2：攻撃者は511,965e18 AFXをコントラクト0x671ce4に転送しました。

  

• ステップ3：攻撃者は残りのAFXを使用して、PancakeSwap V2のAFX-AHTプールで52,316e18 AHTと交換しました。AHTは手数料徴収型トークンであるため、攻撃者は最終的に26,158e18 AHTしか受け取りませんでした。

  

• ステップ4：攻撃者はコントラクト0x560d39を呼び出し、パラメータを100に設定して関数0xb1a87f2c()を起動しました。この関数は0x671ce4からすべてのAFXを引き出したため（攻撃者の寄付トークンを含む）、USDT-AFXおよびAFX-AHTペアの両方に不均衡に大量の流動性を追加しようとしました。ペアにできなかった残りのUSDTおよびAFXは攻撃者に返金され、コストの大部分を回収することができました。

• ステップ5：攻撃者は26,158e18 AHTを1,129,417e18 AFXと交換しました。

  

• ステップ6：攻撃者はフラッシュローンを返済し、残りのAFXをUSDTと交換して、約1万ドルの利益を上げました。

結論

このインシデントは、コントラクト0x560d39がUSDTを交換して取得したAFXを取得する際に、0x671ce4からすべてのAFXを直接引き出したことによって引き起こされました。交換の前後に0x671ce4のAFX残高の変化を確認しなかったことが原因です。

2. OCAインシデント

概要

2026年2月14日、BNB Smart Chain上の未知のプロトコルが悪用され、約42万2千ドルの損失が発生しました。根本原因は不備のあるビジネスロジックでした。スワップ完了後、プロトコルはOCAトークンコントラクトのリサイクル関数を呼び出し、DEXからトークンを取得して、呼び出し元およびその他の指定されたアドレスに返します。OCAトークンのこの片側引き出しは、プールのOCA準備金を人為的に減らし、オンチェーン価格をインフレさせ、攻撃者がUSDCを繰り返し引き出すことを可能にします。

背景

プロトコルコントラクト（0xe0d5ec）は、DEXでユーザー指定量のOCAをUSDCと交換するsellOCA()関数（セレクター0x9c1dad28）を公開しています。OCAにはデフレ型の「リサイクル」メカニズムが含まれています。スワップ後、コントラクトはプールに販売されたのと同じ量のOCAを回収し、呼び出し元およびその他の指定されたアドレスに再分配します。USDCが既に支払われた後でOCAがプールから削除されるため、プールのOCA準備金は減少し、USDC準備金は低く保たれるため、オンチェーンのOCA価格が人為的に上昇します。

脆弱性分析

中核となる脆弱性は、sellOCA()におけるスワップ後の回収が、繰り返し可能な価格操作プリミティブを作成することです。各呼び出しは、DEXプールに対して以下の正味効果をもたらします。スワップ中にプールはUSDCを失い、デフレ機構がプールからトークンを回収する際にOCAも失いますが、呼び出し元はUSDCの収益を受け取り、再分配を通じてOCAを回収します。プールのOCA準備金は、取引を均衡させるための対応するUSDCの流入なしに減少するため、各サイクルでDEX上のOCA/USDC価格が人為的にインフレします。攻撃者は、OCAを購入し、sellOCA()を呼び出して回収をトリガーし、回収したOCAをインフレした価格で販売するというプロセスを繰り返すことで、プールから徐々にUSDC流動性を引き出すことができます。

攻撃分析

攻撃トランザクションの主要なステップは以下の通りです。

• ステップ1：8,704,860e18 USDCをフラッシュローンしました。

• ステップ2：PancakeSwapで8,704,860e18 USDCを940,991e18 OCAと交換しました。

  

• ステップ3：940,991e18 OCAすべてを使用してsellOCA()を呼び出しました。この関数はDEXでOCAをUSDCと交換し、その後、デフレ型リサイクルメカニズムがプールから販売されたOCAを回収して再分配しました――呼び出し元にOCAを返しました。その結果、攻撃者はスワップのUSDC収益を受け取る一方で、OCAトークンも回収しました。プールのOCA準備金は急落し、OCA価格がインフレしました。

  

• ステップ4：回収した940,991e18 OCAを、インフレした価格でPancakeSwapでUSDCに交換し、ステップ2～4を繰り返してプールから徐々に資金を引き出しました。

• ステップ5：最終反復で、攻撃者はわずか9,999e18 OCAを433,238e18 USDC（大幅にインフレしたOCA価格を反映）と交換し、フラッシュローンを返済してエクスプロイトを完了しました。

  

結論

このエクスプロイトの根本原因は、プロトコルのsellOCAフローにおける論理的な欠陥でした。ユーザー提供のOCAをUSDCと交換した後、コントラクトはOCAのデフレ型「回収」メカニズムを通じて事実上すべてのOCA入力をDEXから回収し、呼び出し元およびその他の指定されたアドレスに再分配しました。このスワップ後の回収は、流動性プールに残るOCA残高を人為的に減らし、OCAのオンチェーン価格を急騰させました。攻撃者は「OCAを購入 → sellOCAを呼び出して回収をトリガー → インフレした価格でOCAを売却」を繰り返すことで、比較的少量のOCAでほぼすべてのUSDC流動性を引き出すことができました。

3. SOFインシデント

概要

2026年2月14日、BNB Smart Chain上のSOFトークンが悪用され、約22万5千ドルの損失が発生しました。根本原因は、_update()関数における不備のあるビジネスロジックでした。セル操作中、コントラクトはUniswap V2ペアからバーンアドレスに直接トークンを転送し、すぐにsync()を呼び出しました。このプール準備金の操作により、同じトランザクション内でトークン価格が人為的にインフレしました。攻撃者は、この不正なセルロジックをトリガーするスワップトランザクションを構築し、流動性ペアに自身のトークンをバーンさせ、準備金を更新させることで、人為的にインフレした価格でプールのUSDTをドレインしました。

背景

SOFはBNB Smart ChainにデプロイされたBEP-20トークンであり、カスタムデフレメカニズムと自動手数料管理を備えています。このトークンは、Uniswap V2互換の流動性ペア（特にUSDTとのPancakeSwap）と連携して取引を促進します。

手数料免除ユーザーの場合、売買操作は無料です。その他のすべてのユーザーの場合、購入操作は制限されており、ロールバックされます。

セル操作中、コントラクトはセル量 の90%をペアから_destroyAddressに直接転送し、sync()を呼び出して準備金を更新し、減少した残高を即座に反映させます。

脆弱性分析

根本原因は、0x1f3863コントラクトの_update()関数における不備のあるビジネスロジックです。セル操作中（toがUniswapペアの場合）、コントラクトは467行目を実行します。

 ///  SOF.sol:462-469
462|          } else if (_isPairs[to]) {
463|              //sell
464|
465|              isSell = true;
466|              taxAmount = takeFee(from, amount);
467|              super._update(_uniswapV2Pair, _destroyAddress, amount - taxAmount);
468|              IUniswapV2Pair(_uniswapV2Pair).sync();
469|          }

このロジックは、Uniswapペアアドレスからバーンアドレス（_destroyAddress）に直接トークンを転送し、流動性プールのトークン準備金をドレインします。その後のIUniswapV2Pair(_uniswapV2Pair).sync()の呼び出しにより準備金が即座に更新され、トークン価格が急騰し、攻撃者がプールのUSDTをドレインできるようになります。

攻撃分析

攻撃トランザクションの主要なステップは以下の通りです。

• ステップ1：攻撃者はステップ2のために315,520,309e18 USDTをフラッシュローンし、ステップ3のために875e18 SOFをアドレス0xc4DB5Bに転送しました。

• ステップ2：swapTokensForExactTokens()を介して313,567,718e18 USDTを991,223e18 SOFと交換しました。toアドレスは手数料免除アドレスであり、SOFコントラクトのisExcludedFromFees[to]チェックを満たしたため、_isPairs[from]チェック（そうでない場合、購入操作はロールバックされます）がスキップされました。これにより、_antiFlashloanGuard()チェックもバイパスされます――コントラクトはこの購入操作を記録しないため、ステップ3はブロックされずに進行できます。極めて重要なことに、この大規模な購入は、ペアに787e18 SOF（および313,816,344e18 USDT）のみを残すように設計されました。これにより、ステップ3の準備が整いました。セルロジックにおける90%のバーンは、ペアのほぼすべての残りのSOF残高を破壊します。

• ステップ3：アドレス0xc4DB5Bから、swapExactTokensForTokensSupportingFeeOnTransferTokens()を介して875e18 SOFをUSDTと交換しました。PancakeSwap Router V2は最初にSOF.transferFrom()を実行し、その後スワップを処理します。SOF.transferFrom()中、_update()のセルロジックは875e18（つまり787e18）の90%をペアから_destroyAddressに転送します――これはステップ2で設計されたように、ペアのSOF残高のほぼすべてでした。このバーンとsync()の後、ペアは313,816,344e18 USDTと10e9 SOFのみを保有しました。SOF価格が天文学的にインフレした後、後続のスワップは巨額のUSDT支払いをもたらしました。

• ステップ4：攻撃者はフラッシュローンを返済し、約22万5千ドルの利益を保持しました。

結論

SOFインシデントは、トークン転送ロジック内でAMMプール準備金を操作することのリスクを浮き彫りにしました。セルパスはUniswapペア残高からトークンを削除し、すぐにsync()を呼び出したため、swapExactTokensForTokensSupportingFeeOnTransferTokens()が実行されたとき、ペアへの転送はスワップが完了する前に準備金を変更し、価格を歪ませて抽出を可能にしました。

_antiFlashloanGuard()も実質的な保護を提供しませんでした。これは同じユーザーアドレスの購入と売却のみを制限しており、攻撃者は購入レッグを手数料免除の受領者にルーティングすることでこれを回避しました。

同様の問題を軽減するために、ペアアドレスからトークンを移動したりsync()を呼び出したりする転送フックまたは_update()ロジックは避けてください。アンチフラッシュローンガードが必要な場合は、tx.originを関連アドレスとともに追跡することでトランザクション全体のルールを強制し、攻撃者が1つのトランザクションで異なる受領者に購入と売却を分割できないようにします。

BlockSecについて

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

BlockSecは、著名なカンファレンスで複数のブロックチェーンセキュリティ論文を発表し、DeFiアプリケーションの複数のゼロデイ攻撃を報告し、多数のハッキングを阻止して2,000万ドル以上を救済し、数十億ドルの暗号通貨を保護してきました。

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

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

• 🔗 BlockSec Auditing Service : リクエストを送信

• 🔗 Phalcon Security APP: デモを予約

• 🔗 Phalcon Compliance