Web3 セキュリティインシデント週報 | 2026年4月6日～4月12日

過去1週間（2026年4月6日〜2026年4月12日）、BlockSecは4件の攻撃インシデントを検出し分析し、合計約92万8600ドルの損失が見積もられています。以下の表にこれらのインシデントをまとめ、各ケースの詳細な分析は後続のセクションで提供します。

日付	インシデント	タイプ	見積損失額
2026/04/05*	Denariaインシデント	丸め誤差の非対称性＆安全でないキャスト	約16万5600ドル
2026/04/07	HB Tokenインシデント	ビジネスロジックの欠陥＆価格操作	約19万3000ドル
2026/04/07	Squid Multicallインシデント	任意のコール	約51万7000ドル
2026/04/11	XBITインシデント	アクセス制御の問題	約5万3000ドル

*Denariaインシデントは前週のレポートには含まれておらず、完全性のためここに記載します。

今週から、各レポートの冒頭で1つのインシデントをハイライトします。選択は必ずしも損失額に基づくものではなく、新しいプロトコル設計、巧妙な攻撃技術、またはコミュニティへのより広範な教訓のために選ばれる場合があります。

今週のハイライト：Denariaインシデント

パーペチュアルDEXのDenariaは、複雑なコードロジックに裏打ちされた斬新な会計メカニズムを導入しました。しかし、監査後のリファクタリングで丸め誤差の非対称性が導入され、微妙なエッジケース、つまり負の値が発生する可能性があり、最終的には安全でないキャストにヒットし、天文学的な価値の抽出を可能にしました。

2026年4月5日、Linea上のDenariaのパーペチュアルDEXが、約16万5600ドルの損失で悪用されました。根本原因は、getLpLiquidityBalance()における2つの複合的な欠陥でした。LP残高会計への監査後のリファクタリングで丸め誤差の非対称性が導入され、わずかに負の中間値が発生する可能性があり、さらに、安全でないint256からuint256へのキャストが、この負の値をエラーにするのではなく、サイレントにほぼ最大値の符号なし整数にラップしました。攻撃者は、これを単一サイドのLP預け入れとロングトレードを通じて悪用し、その後、人工的に膨張したPnLをVaultから引き出しました。

背景

Denariaは、動的な仮想AMMを中心に構築されたLinea上のパーペチュアルDEXです。取引と決済を2つのコンポーネントに分離しています。PerpPair市場はユーザーポジションとLP会計を管理し、Vaultは担保を保持し、実現されたPnLを決済します。

PerpPairにおけるLPの所有権は、明示的なトークン残高では表されません。代わりに、プロトコルは2つのブックキーピングコンポーネント（ここではアセットサイドとステーブルサイドと呼びます）で構成される内部会計マトリックスから各LPの状態を再構築します。アセットサイドは、価格変動に対するプールのエクスポージャーのLPのシェアを追跡し、ステーブルサイドは、プールのステーブル建て価値のシェアを追跡します。これら2つのコンポーネントは連携して、LPの価値がどのように追跡および決済されるかを決定します。

重要なのは、これらのコンポーネントは静的なスナップショットとして格納されないことです。取引が発生するたびに、PerpPairはグローバル流動性状態を更新し、各LPの再構築された残高は、累積グローバル値とLPのエントリポイントスナップショットとの差から派生します。この会計メカニズムは、元のシェアベースのアキュムレータを直接残高追跡に置き換えた、監査後のリファクタリングで導入されました。しかし、リファクタリングされた減算パスは、特定の取引シーケンスの下で、再構築されたLPコンポーネントがわずかに負になる可能性のある丸め誤差の非対称性を導入しました。

脆弱性分析

脆弱なPerpPairコントラクト（0xb683...36ae17）には、2つの複合的な欠陥が含まれています。

リファクタリングされた会計における丸め誤差の非対称性。 直接残高追跡を導入した監査後のリファクタリングが、減算パスで丸め誤差の非対称性を生み出しました。特定の取引シーケンスの下で、丸め後のグローバル累積値がLPのエントリポイントスナップショットよりもわずかに小さくなる可能性があり、減算がゼロではなくわずかに負の結果を生み出しました。理論的には、この値はゼロまたはゼロに近いべきでした。この非対称性は、減算会計の一般的な性質ではなく、このリファクタリングされた実装に特有の欠陥でした。

安全でない符号付きから符号なしへのキャスト。 getLpLiquidityBalance()では、再構築されたLP残高コンポーネントが、検証なしにint256からuint256にキャストされました。Solidityでは、負のint256をuint256にキャストしてもエラーにはなりません。値は2^256 moduloでラップされ、-1のような小さな負の数がほぼ最大値の符号なし整数（2^256 - 1）に変わります。この再構築された残高が決済のためのcalcPnL()にフィードされたため、負の入力は巨大なLPポジションとして解釈され、攻撃者は人工的に膨張した利益を実現し、Vaultから資金を引き出すことができました。

どちらか一方の欠陥だけでは悪用されませんでした。丸め誤差の非対称性はわずかに負の値しか生成せず、通常のint256算術では無視できる誤差として扱われました。しかし、その負の値が保護されていないキャストに達すると、ほぼ最大値の符号なし整数にラップされました。その後の境界チェックにより、ラップされた値はプールの総アセットサイド流動性に上限設定され、オーバーフローが事実上市場のアセットサイド全体に対する請求に変換されました。

攻撃分析

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

ステップ1：攻撃者はAaveのフラッシュローンを通じて60,000 USDCを借入しました。
ステップ2：ヘルパーアドレスが30,000 USDCを担保として預け入れ、19,980のステーブルトークンのステーブルのみのLPポジションを追加しました。ステーブルサイドのみを預け入れることで、ヘルパーはアセットサイドLPコンポーネントがほぼゼロから始まることを保証し、丸め誤差で負の領域に突入しやすくなりました。
ステップ3：2番目のヘルパーアドレスが15,000 USDCを預け入れ、100,000のノミナルロングポジションを開設し、liquidityMの更新を引き起こして主要な丸め誤差を導入しました。プール流動性に対するノミナルサイズの大きさは、取引ごとの丸め影響を増幅させ、最初のヘルパーの再構築されたアセットサイド残高をわずかにゼロ以下にしました。
ステップ4：最初のヘルパーはその後realizePnL()を呼び出しました。LP残高の再構築中に、負のlpAssetBalanceはほぼ最大値のuint256にラップされました。この大きな値は市場の全体のアセットサイド流動性に上限設定され、非常に膨張した利益を生み出しました。実質的に、プロトコルはLPが市場のアセットサイド全体を所有していると認識しました。
ステップ5：攻撃者は膨張したPnLをVaultから引き出しました。

残りのVault流動性が枯渇するまで、同じパターンが繰り返されました。フラッシュローンを返済した後、攻撃者は約16万5600ドルの利益を実現しました。

結論

このエクスプロイトは、最終的に符号付きから符号なしへの変換における境界検証の欠如によって引き起こされました。直接的な修正は簡単です。ベアキャストをSafeCast.toUint256()に置き換えること。これは、ラップするのではなく、負の入力でエラーになります。

より広範には、このインシデントは、監査済みのリファクタリングが外部レビューをバイパスすることのリスクを示しています。公式のポストモーテムによると、丸め誤差の非対称性は、チームが元のアクセムレータを直接残高追跡に置き換えた後の最終的な外部監査後に導入されました。リファクタリングはオーバーフローの懸念を解決しましたが、内部テストでは検出されなかった新しいエッジケースを作成しました。プロトコルがコア会計ロジックをリファクタリングする場合、新しいコードパスはセキュリティクリティカルと見なされ、再監査されるべきです。特に、再構築された値がPnL決済または引き出しロジックに直接フィードされる場合はなおさらです。

HB Tokenインシデント

2026年4月7日、BNB Chain上のカスタムERC-20トークンであるHBは、約19万3000ドルの損失で悪用されました。根本原因は報酬決済ロジックの欠陥でした。トリガーされると、swapBack()が呼び出され、PancakeSwapペアから直接HBリザーブを削除し、その後sync()を呼び出してプールを再価格設定しました。攻撃者がペアのHBの大部分を買い占めた後、その後のswapBack()実行により、残りの流動性がさらに減少し、スポット価格が急激に上昇しました。攻撃者はその後、歪んだプールに少量のHBを売却し、不均衡に大きな量のUSDTを得て、ペアが枯渇するまでこのサイクルを繰り返しました。

背景

HBは、BNB Chain上のカスタムERC-20トークンであり、_transfer()に購入/販売フックが埋め込まれています。ユーザーがAMMペアから購入すると、_handleBuy()はコストベースの情報記録を行います。ユーザーが売却すると、_handleSell()はペアの状態に応じて、異なる税金と決済パスに分岐します。

このトークンには、swapBack()をトリガーできる報酬決済メカニズムも含まれています。通常のルーターを介したスワップを実行する代わりに、swapBack()はHBをPancakeSwapペアから直接PROOFアドレスに転送し、その後ペアにsync()を強制して同期させます。これにより、コントラクトは通常のAMM取引フローの外でペアのHBリザーブを縮小し、プールの価格を即座に引き上げることができます。

脆弱性分析

HBトークンコントラクト（0x62ce...87a4b0）の根本的な欠陥は、swapBack()がトレジャリーやルーターを介したスワップからではなく、AMMペアから直接トークンを調達していたことでした。swapBack()は報酬決済パスから到達可能であったため、取引ではないコードパスがペアリザーブを直接変更し、スポット価格を変動させることができました。

ペアのHBリザーブが少ない場合、swapBack()の呼び出しは残りのHBをさらに減らし、価格の歪みを増幅させ、極端に高い価格で少量のHBを売却することを可能にします。

攻撃分析

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

ステップ1：攻撃者はVenusから大量の資金を借入しました。
ステップ2：攻撃者は約1,496 HBをトークンコントラクトに転送し、コントラクトのHB残高を増加させ、その後のswapBack()がペアからより多くの量を引き出せるようにしました。
ステップ3：PancakeSwapペアにわずかな量のHBを転送することで、攻撃者は_swapAndLiquify()をトリガーし、トークンコントラクトが保有する約4,163 HBを10 USDTとスワップし、攻撃者の請求可能なHB報酬を増加させました。

ステップ4：攻撃者はその後、72,117,360 USDTを費やして73,608,753 HBを購入し、ペアにはHB流動性がほとんど残らない状態になりました。

ステップ5：次に、攻撃者は報酬不足パスをトリガーしました。報酬を満足させるために、トークンはswapBack()を呼び出し、PancakeSwapペアから追加のHBを引き出し、sync()を強制してHB価格を急激に上昇させました。

ステップ6：攻撃者は直接USDTをペアに転送してUSDTリザーブを補充し、その後、歪んだ価格でわずか0.000582 HBを37,582,322 USDTで売却しました。

歪んだ価格でHBトークンを売却するためにステップ6を繰り返すことにより、攻撃者はプールからほぼすべてのUSDTを抽出しました。

結論

HBトークンインシデントは、報酬ロジックがAMMリザーブを直接変更することを許可することの危険性を示しています。リザーブに影響を与える関数は、報酬決済パスから到達可能であってはならず、プロトコルはセキュリティクリティカルな制御フローにおいて、内部トークン残高とAMMリザーブ会計を混同することを避けるべきです。内部的にプールを摂動させた後のスポットAMM価格設定に依存する設計は、本質的に価格操作に対して脆弱です。

Squid Multicallインシデント

2026年4月7日、Squidユーザーは、承認関連のインシデントで複数のチェーンにわたって約51万7000ドルを失いました。ユーザーは、意図したSquid Routerではなく、誤ってSquidMulticallコントラクトを承認しました。これにより、攻撃者は許可されていないSquidMulticall.run()関数を呼び出して、任意の外部コールを実行できるようになりました。したがって、攻撃者は、コントラクトに承認された任意の許可を使用して、承認したユーザーに対してトークンのtransferFrom()コールを実行できました。

背景

Squidの通常のフローでは、ユーザーはSquid Routerを承認すべきであり、SquidMulticallは実行ヘルパーとしてのみ機能します。ヘルパーコントラクトは、ルーティングロジックの一部としてバッチコールを実行するように設計されていますが、トークン転送のためにユーザーが直接承認する支出者であってはなりません。

ERC-20の承認チェックは支出者アドレスに対してのみ実行されるため、ユーザーの承認と無制限の任意のコール機能を組み合わせたコントラクトは、危険な承認シンクを作成します。承認されると、そのコントラクトは、誰かがそのコールを制御できる場合、一般的なトークン引き出しベクトルになる可能性があります。

脆弱性分析

このインシデントはスマートコントラクトの脆弱性によって引き起こされたものではありません。損失は、2つの条件が同時に発生したことによって生じました。意図したSquid RouterではなくSquidMulticallを対象とした誤った承認、およびrun()の許可されていない設計が、任意のターゲットとキャルデータを任意の呼び出し元から受け入れたことです。

SquidMulticallは、信頼されたルーティングロジックによって入力が構築される、Routerフローの下流ステップとしてバッチコールを実行するように意図されています。意図されたとおりに使用された場合、許可されていない設計はリスクを伴いません。しかし、誤った承認はそれを完全に変えます。MEVボットはアクティブな承認を検出し、細工されたキャルデータでrun()を呼び出してtransferFrom(victim, attacker, amount)を呼び出し、被害者のさらなるアクションなしに各チェーンで承認されたトークンを枯渇させました。

攻撃分析

このインシデントは、BNB Chain、Arbitrum、Optimism、Avalanche、Baseのユーザーに影響を与えました。以下の分析は、攻撃トランザクション 0x81d0c4...9b1301e9に基づいています。

ステップ1：被害者（0xacc0...f40e98）は、意図したSquid Routerではなく、誤ってSquidMulticallを承認しました。
ステップ2：MEVボットはこの承認を検出し、細工されたキャルデータでSquidMulticall.run()を呼び出しました。
ステップ3：任意のコールを通じて、SquidMulticallはtransferFrom(victim, attacker, amount)を呼び出し、承認された資産を被害者のウォレットから転送しました。

結論

このインシデントは、ユーザー向け承認フローと共存する許可されていない任意のコールコントラクトのリスクを示しています。直接的な原因は誤った承認であり、SquidMulticallが制限のない呼び出し元、任意のターゲット、および任意のキャルデータを受け入れたため、誤ってそれに向けられた任意の承認は即座に完全に悪用可能でした。実行ヘルパーコントラクトを使用するプロトコルは、呼び出し元制限を追加するか、そのような関数で許可されるコールターゲットを制約することを検討すべきです。これにより、誤った承認が簡単に武器化されることを防ぐことができます。

XBITインシデント

2026年4月11日、BNB Chain上のXBITトークンが約5万3000ドルの損失で悪用されました。根本原因はXBITVaultのフェイルオープンアクセス制御の欠陥でした。transfer()関数の承認チェックは条件付きでした。xbitContractがゼロでない場合にのみmsg.sender == xbitContractを強制し、それ以外の場合はサイレントにパスしました。bindXBIT()がコントラクトの初期化のために呼び出されていなかったため、この欠陥は永続的に露呈し、任意の呼び出し元が任意のXBIT残高を任意のXBIT/USDT PancakeSwapペアを含むアドレスから移動できるようになりました。攻撃者はこれを利用してペアからXBITを枯渇させ、その後、少量のXBITをプールに繰り返し売却し、不均衡に大きな量のUSDTを得ました。

背景

XBITVaultは受動的なトレジャリーコントラクトではありません。XBITトークンシステムの残高と承認のバックエンドであり、transfer()、approve()、mintForXBIT()などのトークンライクな関数を公開しています。意図された設計では、オーナーはまずbindXBIT()を呼び出して、xbitContract、pancakePair、pairContract、およびxbitDecimalsを設定してVaultを初期化する必要があります。初期化後、機密性の高い状態変更関数は、バインドされたXBITコントラクトによってのみ呼び出されることになっていました。言い換えれば、Vaultのセキュリティモデルは、公開使用前の初期化の成功にかかっています。

脆弱性分析

重大な欠陥は、脆弱なXBITVaultコントラクト（0xc879...42391a）におけるアクセス制御が条件付きであることです。transfer()関数は、xbitContract != address(0)の場合にのみmsg.sender == xbitContractをチェックします。これは、xbitContractが設定されていない場合、関数はエラーにならず、代わりに誰でも呼び出せるようになることを意味します。残高は_balancesに格納されているため、ソースアドレスに十分な残高があれば、外部の呼び出し元は任意のXBIT残高を任意のアドレスから任意のアドレスに移動できます。

意図された初期化パスはbindXBIT()でしたが、一度も呼び出されなかったため、Vaultは初期化されておらず、フェイルオープンの状態のままでした。結果として、実質的に制限のない任意の残高転送プリミティブが使用可能になりました。

攻撃分析

以下の分析は、攻撃トランザクション 0xbc877f...4df1b694に基づいています。

ステップ1：攻撃者は、制限のないtransfer()関数を通じて、対応するUSDTを提供せずに、XBIT/USDTペアから1,526,216.569 XBITを移動しました。
ステップ2：攻撃者はsync()を呼び出して、ペアのXBITリザーブをわずか1〜2ユニットに縮小しました。
ステップ3：ペアにXBIT流動性がほとんど残らない状態になった後、攻撃者は繰り返しXBITを売却し、ペアから約53,112 USDTを枯渇させました。

結論

このインシデントは、初期化に依存するアクセス制御チェックがフェイルオープンしたことが原因でした。xbitContractが設定されていない場合、transfer()は制限がなく、bindXBIT()が一度も呼び出されなかったため、Vaultは永続的に公開の任意の残高転送プリミティブを公開しました。特権関数は、初期化が完了するまでエラーになるべきであり、デプロイメント時のバインディングステップは、運用上の想定ではなく、オンチェーンで強制される前提条件であるべきです。

BlockSecについて

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

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

公式ウェブサイト：https://blocksec.com/
公式Twitterアカウント：https://twitter.com/BlockSecTeam
🔗 BlockSec監査サービス : リクエストを送信
🔗 Phalcon Security APP: デモを予約
🔗 Phalcon Compliance