損失額1,590万ドル：Trusted Volumes、Wasabi等の被害 | BlockSec週間レポート

過去2週間（2026年4月27日〜2026年5月10日）の間、BlockSecは複数のブロックチェーンエコシステム全体で複数の攻撃インシデントを確認しました。以下の表は、推定総損失額が約1,590万ドルにのぼる、注目すべき11のインシデントを一覧にしたものです。

日付	インシデント	タイプ	推定損失額
2026/04/27	不明なコントラクトインシデント	アクセス制御の問題	約70.8万ドル
2026/04/27	ZetaChainインシデント	アクセス制御の問題	約33.4万ドル
2026/04/28	JetonRouterインシデント	ビジネスロジックの欠陥	約22.9万ドル
2026/04/28	QNTインシデント	アクセス制御の問題	約12.5万ドル
2026/04/28	JUDAOトークンインシデント	アクセス制御の問題	約22.8万ドル
2026/04/29	不明なコントラクトインシデント	アクセス制御の問題	約98.3万ドル
2026/04/29	Ycdeal3インシデント	アクセス制御の問題	約39.8万ドル
2026/04/29	Aftermath Financeインシデント	ビジネスロジックの欠陥	約114万ドル
2026/04/30	Wasabi Protocolインシデント	鍵の漏洩	約570万ドル
2026/05/07	Trusted Volumesインシデント	不十分な入力バリデーション	約587万ドル
2026/05/10	Renegade.fi Darkpool Proxy	アクセス制御の問題	約22万ドル

攻撃の新規性、経済的影響、セキュリティへの影響に基づき、以下の3つのインシデントを詳細分析の対象として選定しました。

Aftermath Finance: パーペチュアルDEXに対する現実の攻撃。手数料バリデーションにおける、符号付き/符号なしの微妙なセマンティクスの不一致が、プロトコル資金の完全な流出につながりました。
Trusted Volumes: 大規模な経済的影響（約587万ドル）があり、RFQ決済ロジックにおける認証の不一致が明確に示されました。
Wasabi Protocol: インフラからコントラクト制御への侵害。監査対象としては認識されにくいものの、ますます一般的になっている攻撃手法です。

週刊ハイライト: Aftermath Finance

このインシデントを取り上げる理由は、符号付き/符号なしセマンティクスの不一致が、特定のプロトコルに留まらない微妙な脆弱性クラスであるためです。符号付き固定小数点ライブラリを使用して符号なし手数料や価格値をバリデーションするDeFiプロトコルはすべて、同じ攻撃パターンの影響を受ける可能性があります。そのため、この攻撃事例は開発者と監査人の双方にとって非常に有益です。

2026年4月29日、Sui上のオンチェーン無期限先物取引所であるAftermath Perpetualsが攻撃を受け、約114万ドルのUSDCが流出しました [1]。根本原因は、プロトコルのビルダー手数料バリデーションにおける符号付き/符号なしセマンティクスの不一致でした。手数料比較関数が符号なしの値に対して符号付き演算を実行したため、攻撃者は符号付き解釈で「負」として扱われる手数料値を提出することができました。決済時、この負の手数料が正の担保クレジットに変換され、攻撃者はプロトコル保管庫から水増しされた資金を引き出すことができました。

背景

Aftermath Perpetualsは、Sui上のオンチェーン無期限先物取引所です [2]。このプロトコルでは、外部インテグレーターがフロントエンドインターフェースを構築することで取引手数料を得ることができます。各インテグレーターは、インターフェースを利用するトレーダーに課される手数料率（taker_fee）を設定します [3]。安全策として、トレーダーはインテグレーターが課金できる最大手数料を制限する「事前設定手数料率上限（maxTakerFee）」を設定することで、インテグレーターを承認することができます。

成行注文を実行する際、プロトコルはまずtaker_feeとmaxTakerFeeを比較し、手数料がトレーダーの承認範囲内に収まっていることを確認した後、テーカーの担保から計算された手数料を差し引き、インテグレーターの記録にクレジットとして加算します。

プロトコルの演算は符号付き固定小数点ライブラリ（ifixed）に基づいており、値をu256整数として表現しつつも、比較や算術演算では2の補数形式として解釈します。

脆弱性分析

バグのあるコントラクトには、インターフェースモジュール（0x9e2080...25d136）と、クリアリングハウスモジュール（0x21d001...7c5068）が含まれます。

脆弱性はcalculate_taker_fees()関数にあり、ifixed::less_than_eq()を使用してインテグレーターのtaker_feeをトレーダーのmaxTakerFeeと比較しています。

assert!(
    ifixed::less_than_eq(
        v5.taker_fee,
        account::get_integrator_max_taker_fee(
            account::get_integrator_config(arg1, v5.integrator_address)
        )
    ),
    errors::invalid_integrator_taker_fee()
);

taker_feeとmaxTakerFeeは、意味的には非負の手数料率です。しかし、ifixed::less_than_eq()はu256に対して符号付き比較を実行します。maxTakerFeeが0に設定されている場合、2^256 - 10^16のような値が符号付きセマンティクスで-10^16と解釈されます。-10^16 <= 0は真であるため、チェックを通過してしまいます。

この脆弱性は、create_integrator_info()が公開されており、提供されたtaker_feeに対して権限や手数料範囲のバリデーションを強制していないことで、さらに悪用が容易になっています。

public fun create_integrator_info(arg0: address, arg1: u256): Option<IntegratorInfo> {
    let v0 = IntegratorInfo {
        integrator_address : arg0,
        taker_fee          : arg1,
    };
    option::some<IntegratorInfo>(v0)
}

この「負の手数料」は受け入れられるだけでなく、決済時に正の担保クレジットへと変換されます。決済パスにおいて、担保はcollateral += pnl - taker_fee - builder_feeのように更新されます。builder_feeが負の場合、それを差し引くことは加算と同義になります。

position::add_to_collateral_usd(
    arg0,
    ifixed::sub(v6, ifixed::add(v7, v8)),
    arg2
);

手数料バリデーションも決済演算も、手数料値が非負であることを強制していません。そのため、「符号付き比較が負の値を流入させ、符号付き演算がそれを担保クレジットに変換する」という2つのチェックの欠如が組み合わさって悪用を可能にしました。

攻撃分析

以下の分析は、トランザクション 4pGQdf...wVD8 に基づいています。

ステップ1: 攻撃者は100e6 USDCを2つの新しい無期限先物アカウント（1227および1228）に分割しました。これにより隔離されたコンテキストが作成され、攻撃者はメイカー（1227）とテーカー（1228）の両方の役割を果たすことが可能になりました。
ステップ2: 攻撃者は100e6 USDCをアカウント1227に担保として預け入れ、指値注文を出して次のテーカー注文に対する相手方を提供しました。
ステップ3: 攻撃者はインテグレーター保管庫を作成し、maxTakerFee = 0としてアカウント1228の設定を追加しました。上限を0に設定することが鍵でした。これにより、符号付き比較taker_fee <= 0が、2の補数表現で「負」に見えるあらゆる値を受け入れるようになります。
ステップ4: 攻撃者はアカウント1227からセッションを開始し、order_size = 100e6で指値注文を出し、アカウント1228が取引する流動性を用意しました。
ステップ5: 攻撃者はtaker_fee = 2^256 - 100e6（符号付きifixedセマンティクスで-100e6を表す値）を指定してcreate_integrator_info()を呼び出しました。関数が公開されており検証を行わないため、呼び出しは成功しました。
ステップ6: 攻撃者は悪意のあるインテグレーター情報を使用して、アカウント1228から成行注文を実行しました。符号付き手数料比較が通過し（-100e6 <= 0）、決済中に負の手数料が担保から差し引かれたことで、結果として100e6の無料担保がアカウント1228に追加されました。
ステップ7: 攻撃者はアカウント1228から水増しされた担保を割り当て解除して引き出し、79,610 USDCを獲得しました。攻撃者は複数のトランザクションでこのパターンを繰り返し、合計で約114万ドルを蓄積しました。

結論

このインシデントは、Aftermath Perpetualsのビルダー手数料バリデーションにおける、符号付き/符号なしセマンティクスの不一致によって引き起こされました。本質的な問題は、手数料比較関数（ifixed::less_than_eq）が、符号なしであるべき手数料値を符号付きセマンティクスで解釈した点にあります。これに境界チェックを行わない公開された手数料設定関数が組み合わさることで、攻撃者は符号付き比較を「負」として通過させ、決済時に正の担保として変換させることが可能となりました。

より広い教訓として、本質的に非負であるべき値（手数料、価格、金額）の検証に符号付き固定小数点ライブラリを使用するプロトコルはすべて、同じクラスの攻撃に対して脆弱であることを認識すべきです。緩和策としては、（1）比較前に手数料が非負であることを強制する（assert!(taker_fee >= 0)）、（2）create_integrator_info()を承認された呼び出し元に制限する、（3）意味的に符号なしである値には符号なし比較関数を使用する、などが挙げられます。

参考文献

本期間のその他のインシデント

Trusted Volumes

2026年5月7日、Ethereum上にデプロイされたカスタムRFQ（Request-For-Quote）プロキシコントラクトが攻撃を受け、マーケットメイカーであるTrustedVolumesから約587万ドルが流出しました。根本原因はRFQ実装コントラクトの注文実行関数における承認の不一致でした。署名者権限検索とトークン転送操作が注文の異なるフィールドを参照していたため、一方のアドレスで承認チェックが通過する一方で、資金は別のアドレスから引き落とされました。攻撃者は約1,291 WETH、20.6万 USDT、16.94 WBTC、127万 USDCを流出させました。

背景

TrustedVolumesは、EthereumにデプロイされたRFQプロトコル上でマーケットメイカーとして運営されています。マーケットメイカーはオフチェーンで署名済みの価格クォートを継続的に生成し、テーカー（通常はトレーダーやアグリゲータールーター）が選択したクォートをオンチェーンで提出します。プロトコルコントラクトは署名を検証し、transferFromを通じてメイカーとテーカーの間でトークンを移動させることで取引をアトミックに決済します。このプロトコルは「保管庫なし」設計を採用しており、資金を直接管理することはありません。各メイカーは、引用するすべてのトークンに対してプロトコルコントラクトに事前にERC-20アローワンスを付与し、プロトコルはフィル（決済）のタイミングでメイカーのウォレットから直接トークンを引き出します。

メイカーが署名操作をホットウォレットに委任できるようにするため、プロトコルコントラクトはメイカーごとの署名者レジストリを保守しています。メイカーはregisterAllowedOrderSigner(signer, allowed)を呼び出してホットキーをホワイトリスト登録することができ、その後のその鍵による注文はメイカー本人が署名したものとして扱われます。

脆弱性分析

RFQプロキシコントラクトは0xeEeEEe...051756に、実装コントラクトは0x88eb28...2760d8にデプロイされています。

RFQ実装コントラクトの注文実行関数0x4112e1c2()は、ecrecover()を通じて署名者を復元し、allowedOrderSignerマッピングを確認して署名を受け入れるかどうかを決定します。このチェックの検索キーは注文のテーカー側アドレスであるvarg4です。しかし、その後の資金を引き落とすtransferFromでは、注文のメイカーフィールドであるvarg5が使用されます。varg4とvarg5は注文構造体の独立したフィールドであるため、承認チェックと資金流出操作が異なる主体を参照していることになります。承認された署名者ドメインがトークンの引き落とし元アドレスと一致することを強制するチェックは存在しません。

registerAllowedOrderSigner関数は外部キーとしてmsg.senderでホワイトリストに書き込みますが、実行パスではvarg4を外部キーとして読み取ります。varg4の呼び出し元が以前にregisterAllowedOrderSignerを通じて自身を登録していれば、varg5にどの第三者メイカーアドレスが表示されていようとも、承認チェックは通過してしまいます。

攻撃分析

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

ステップ1: 攻撃者は攻撃用コントラクトを展開し、それを通じてregisterAllowedOrderSignerを呼び出し、攻撃者のEOA（外部所有アカウント）を許可された署名者ホワイトリストに登録しました。これにより、攻撃者が署名した注文がプロトコルの署名認証を通過することが保証されました。

ステップ2: 攻撃コントラクトは攻撃者自身から4 weiのUSDCを引き出し、RFQプロトコルに4 weiを承認しました。これにより、攻撃コントラクトがテーカーとして行動するための最低限の条件が整いました。
ステップ3: 攻撃者は4つの注文を偽造しました。それぞれは攻撃者のEOAによって署名され、TrustedVolumesをメイカーとして指名していました。署名チェックがvarg4（攻撃者のコントラクト）を参照する一方で、transferFromがvarg5（TrustedVolumes）から引き落とすため、各注文はTrustedVolumesから資金を流出させました。4つの注文は、それぞれUSDCを1 wei分交換することで、1,291 WETH、206,282 USDT、16.939 WBTC、1,268,771 USDCを奪い取り、合計で約587万ドルの利益を上げました。

結論

根本的な欠陥は、注文実行関数における承認の不一致です。署名者権限チェックに使用されるアドレスと、実際に支払うアドレスが異なります。具体的には、registerAllowedOrderSignerはmsg.senderを元に書き込みを行い、実行パスはテーカーフィールド（varg4）を元に読み取りを行い、transferFromはメイカーフィールド（varg5）から引き落とします。これらの3つの操作が異なる主体を参照しているため、独自の署名者を登録した攻撃者は、第三者メイカーを標的とした注文を偽造できます。資産の移動を許可する認証チェックは、実際に支払うアドレスに基づいて行われる必要があり、書き込みパスと読み取りパスは同じキーを使用しなければなりません。

Wasabi Protocol

2026年4月30日、複数のEVMチェーンに展開されているオプションおよび無期限先物プロトコル「Wasabi Protocol」がセキュリティインシデントに見舞われ、約570万ドルの損失（ユーザー資金480万ドル、Wasabi財務から90万ドル）が発生しました [1][2]。この攻撃はインフラの侵害から始まりました。公開サーバー上の露出した分析エンドポイントから資格情報が漏洩し、それが最終的にプロトコルのEVMスマートコントラクトを制御する秘密鍵の盗難につながりました。攻撃者はその鍵を使用して、Ethereum、Base、Blast、Berachainにまたがる複数のWasabi保管庫から不正な引き出しを実行しました。

背景

Wasabi Protocolは、EVMチェーン（Ethereum、Base、Blast、Berachain）およびSolanaに展開されています。今回のインシデントはプロトコルのEVM側の展開に限定されており、Solanaの展開やProp AMMは影響を受けませんでした。

WasabiのEVMコントラクト（WasabiLongPool、WasabiShortPool、WasabiVault）は、特権鍵を介して管理されています。プロトコルは、Spring Boot上に構築された分析および監視サービスを含むオフチェーンインフラも実行しています。

攻撃分析

このインシデントは、インフラからコントラクト制御への侵害経路を辿りました。

ステップ1: 攻撃者は、公開されているWasabiサーバーにSpring Boot Actuatorがインストールされていることを発見しました。通常、Actuatorのヒープダンプはパスワードで保護されていますが、このサーバーは標準のパスワード保護メカニズムと非互換な別のSpringフレームワークのバリアントを使用しており、ヒープダンプのエンドポイントが露出したままになっていました。
ステップ2: 攻撃者はヒープダンプを回収し、そこには別の内部サーバー用の資格情報が含まれていました。
ステップ3: 漏洩した資格情報を使用して、攻撃者は内部サーバーへピボット（転身）し、WasabiのEVMスマートコントラクトを制御する秘密鍵を入手しました。
ステップ4: 特権鍵を手に入れた攻撃者は、Ethereum、Base、Blast、Berachainの各チェーン上でWasabiLongPool、WasabiShortPool、WasabiVaultコントラクトに対して不正な引き出しフローを実行し、合計約570万ドルを引き出しました。

結論

このインシデントは、スマートコントラクトのセキュリティがコードレベルだけでは完結しないことを示しています。この悪用にオンチェーンの脆弱性は一切必要なく、攻撃者は純粋にインフラの露出を通じて制御権を獲得しました。重要な教訓は以下の通りです。（1）デバッグや分析用インターフェース（ヒープダンプ、プロファイリングエンドポイント、ログエクスポートなど）は、公共インフラ上で絶対にアクセス可能にしてはならない。（2）本番システムの資格情報は、分析や監視環境と厳格に分離しなければならない。（3）スマートコントラクトの管理用鍵は、マルチシグ保管、ハードウェアによる署名、役割分離、リアルタイム監視、緊急停止手順など、多層防御コントロールによって保護されるべきである。

参考文献

BlockSecについて

BlockSecは、フルスタックのブロックチェーンセキュリティおよび暗号資産コンプライアンスプロバイダーです。当社は、顧客がコード監査（スマートコントラクト、ブロックチェーン、ウォレットを含む）を実行し、攻撃をリアルタイムで遮断し、インシデントを分析し、不正資金を追跡し、AML/CFT義務を遵守することを支援する製品およびサービスを開発しています。プロトコルやプラットフォームのライフサイクル全体を通じて、これらの専門知識を提供しています。

BlockSecは、権威あるカンファレンスで複数のブロックチェーンセキュリティ論文を発表し、DeFiアプリケーションの「ゼロデイ攻撃」を複数報告し、複数のハッキングを阻止して2,000万ドル以上の救済に成功し、数十億ドル相当の暗号資産を保護してきました。

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