約1,130万ドル(11.3M)の損失:Multicall Router、Nostra

先週(2026/09/14 - 2026/09/20)、合計推定損失額約1,130万ドルに相当する2件のセキュリティインシデントを確認しました。

日付	インシデント	種類	推定損失額
2026/09/15	Unknown Multicall Router	不適切なアクセス制御	約780万ドル
2026/09/17	Nostra Finance	欠陥のあるオラクル設定	約350万ドル

今週のハイライト: Unknown Multicall Router

このインシデントが選ばれた理由は、ネストされたルーター呼び出し全体にわたる呼び出し元アイデンティティの微妙な変化が、カスタムモジュールを実行していたSafeウォレットの認可を突破し、多額の資産引き出しを可能にしたためです。

2026年9月15日、Yoinkという名前で活動するMEVボットが、カスタム戦略モジュールを通じて資産を管理していたSafeウォレットに対する攻撃の試みをフロントランし、約780万ドルの推定損失が発生しました[1]。リクエストはマルチコールルーターを介してこれらのモジュールに到達しましたが、そこでネストされた呼び出しの認可エラーにより、信頼できない命令がモジュールチェーンに渡ることが許され、再利用可能な権限が不正な操作をさらに助長しました。

背景

Safeウォレットは、Safeモジュールを有効化できます。一度有効化されると、モジュールはexecTransactionFromModule()を呼び出して、マルチシグの承認なしにウォレットに操作を実行するよう指示できるため、有効化されたモジュールはウォレットの資産に対する恒常的な特権となります。被害を受けたSafeウォレットは、Gatewayモジュールと LPモジュールという2つの戦略コンポーネントを有効化していました。

Gatewayモジュールは再利用可能なコマンドテンプレートを定義しており、それぞれが被害を受けたSafeウォレットが実行を許可されている操作を記述し、具体的な値は実行時に埋め込まれます。このモジュールは、自身の認可済み呼び出し元リストに載っている呼び出し元からのコマンドのみを受け付けました。各実行には、呼び出されているコマンドテンプレートを認証するために、保存されたルートと照合されるMerkle証明も必要でした。一部のテンプレートは、ウォレットの資産を使用してUniswap v4の流動性操作を行うLPモジュールをウォレットに呼び出すよう指示しました。したがって、制御は1つのモジュールから次のモジュールへ直接渡されるのではなく、ウォレット自体を経由して戻ってきました:

Authorized Caller
       |
       v
Gateway module -- verify(command, Merkle proof, root)
       |
       | execTransactionFromModule(...)
       v
Safe wallet context
       |
       v
   LP module --> mintPosition(...)

このインシデントの実行者はGatewayモジュールを直接呼び出しませんでした。リクエストはマルチコールルーターを通じて到着し、ルーターが彼らの代わりにバッチ処理された呼び出しをディスパッチしました。ルーターが正当なリクエストを転送する際には常に直接の呼び出し元であったため、Gatewayモジュールの認可済み呼び出し元リストにはルーター自体が含まれていました。

この経路を通じて、被害を受けたSafeウォレットは、供給されたrsETHに対するAaveのレシートトークンであるaEthrsETHをUniswap v4プールに預け入れ、ポジションNFTをウォレットに鋳造することができました。aEthrsETHの保有者であれば誰でも、Aaveを通じてそれをバーンし、原資産のrsETHを引き出すことができました。

被害を受けたSafeウォレットは、そのAave担保に対して借り入れも行っていました。そのため、Aaveは担保価値と負債の比率であるヘルスファクターを追跡しており、ファクターが1を下回る結果となる担保移転を拒否します。

脆弱性分析

0x4f00...8ebCにあるルーターはソース検証されていません。したがって、以下の記述は、権威あるソースレベルの名称ではなく、デプロイされたバイトコード、逆コンパイルされたロジック、トランザクショントレース、および公開されているフォークテストの再構築に基づいています。

ルーターのディスパッチロジックは、ホワイトリストに載っているターゲットまたはルーター自身のアドレスのいずれかを受け入れ、そのターゲットの認可済み呼び出し元リストを現在の呼び出しのmsg.senderと照合していました。ルーターが自身に対して行う呼び出しをまたいで元の外部呼び出し元のアイデンティティを保持する仕組みは何もありませんでした。

ルーターが自身を呼び出す際、内部呼び出しはルーターをmsg.senderとして観測しました。認可ヘルパーは、自己ターゲットのケースではルーターを受け入れ、それ以外の場合は現在のmsg.senderが次のターゲットの認可済み呼び出し元リストに含まれているかどうかを確認しました。その結果、Gatewayモジュールをターゲットとする内部呼び出しは、外部呼び出し元からではなく、すでに認可されたルーターから発信されたものとして評価されました。これにより、信頼できない発信元からの命令が、このネストされた経路を通じてGatewayの呼び出し元認可を満たすことが可能になりました。

2つ目の欠陥は、証明チェック自体にありました。証明はコマンドテンプレートを認証しましたが、それと一緒に提供される実行時パラメータを束縛するチェックは存在しませんでした。そのため、以前の正当なコマンドに対して発行された有効な証明は、その具体的な実行値が変更された後も使用可能なまま残りました。再利用された証明は使用可能な権限を提供しましたが、信頼できない呼び出し元がそもそもGatewayモジュールに到達できたのは、ネストされた認可バイパスによるものでした。

攻撃分析

同じコマンドテンプレートに対して以前発行されたMerkle証明が、異なる実行時の値でも使用可能なまま残っていました。この性質単独ではGatewayの呼び出し元認可をバイパスできませんでしたが、ネストされたルーター経路がその認可チェックを満たした後、使用可能な権限を提供しました。

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

成功したトランザクションの前に、元の攻撃者は攻撃用コントラクト、攻撃者が制御するPATトークン、および後にPATのスワップを実行する2つ目のコントラクトをデプロイしました。

次のブロックで、攻撃者はprepare()を呼び出して、PAT/aEthrsETHのUniswap v4プールを作成・初期化しました。

YoinkのMEVボットは保留中の攻撃を検知し、準備された攻撃用コントラクトを呼び出すことで元の攻撃者をフロントランしました。その結果生じた呼び出しはルーターに入り、ルーターに自身を呼び出させ、その後ルーターをmsg.senderとしてGatewayモジュールに到達しました。有効化されたモジュールであるため、Gatewayはマルチシグの承認なしに、提供された操作を被害を受けたSafeウォレットに実行させることができました。

この命令により、被害を受けたSafeウォレットは約2,900のaEthrsETHを、ティック範囲[10, 20]内で攻撃者が制御するPAT/aEthrsETHプールに流動性として供給しました。このトランザクションは関連するUniswap v4ポジションNFTもウォレットに鋳造し、この操作が予想される流動性フローの範囲内であるように見せかけました。これによりウォレットのaEthrsETH残高全体が奪われることはありませんでした。金額はAaveのヘルスファクターチェックが通過するように上限が設定されており、ウォレットのヘルスファクターは1.001182484056805114のままでした。

その後、攻撃用コントラクトは、攻撃者が制御するPATを、その2つ目のコントラクトを通じて、預け入れられたaEthrsETHのほぼ全量と交換しました。取得したレシートトークンをAaveを通じてバーンし、対応する量のrsETHを引き出しました。Yoinkボットに到達した約2,900のrsETHのうち、約2,882.37のrsETHはその利益受取先に送られ、約17.63のrsETHはETHに交換され、結果として得られたETHのほぼ全額がブロックビルダーに支払われました。

結論

根本原因は、単一のSafeウォレットに付随するカスタムインフラの認可上の欠陥であり、すべての実行パラメータを束縛しない権限によってさらに悪化しました。これは、Safe、Aave、Uniswap v4、またはKelpのコアコントラクトに帰すべきものではありません。

他者の代わりに呼び出しを転送するコンポーネントは、呼び出しチェーンの途中で取得されたアイデンティティではなく、元の外部呼び出し元に基づいて認可を判断すべきであり、また自身をターゲットとして到達可能であるべきではありません。同様に、権限は操作が属するテンプレートだけでなく、その操作が実行される具体的な値も束縛すべきです。

今週のその他のインシデント

Nostra Finance

2026年9月17日、NostraのStarknetマネーマーケットが、水増しされたNSTRオラクル価格を通じて悪用され、過大評価された担保に対して約350万ドルの資産が借り入れられました。根本原因は、価格ソースが不十分な数しか受け入れないオラクル統合の設定であり、これにより操作された薄いプールのクォートが集約価格に大きな影響を与えることが可能になりました。Nostraはマーケットを一時停止し[2]、Pragmaは攻撃者のアドレスが凍結され、復旧作業が進行中であると報告しました[3]。最終的な損失額と回収の可能性は依然として不明です。

背景

Nostraは、ユーザーが対応する担保を供給し、その担保のオラクル由来の価値に応じて他の資産を借り入れることができるマネーマーケットをStarknet上で運営していました。

Nostraは、独自の価格フィードコントラクトを通じてNSTRの価格を取得しており、このコントラクトはStarknet上で集約価格を公開するオラクルであるPragmaを読み取るメインオラクルコントラクトに委任していました。パブリッシャーは、AVNUやGECKOTERMINALを含む名前付きソースの下でPragmaに観測値を提出しており、文書化されたNSTRの設定は、そのうち3つのソースの中央値を記述していました[4][5]。各オラクルの応答には、価格、小数精度、タイムスタンプ、および寄与ソース数が含まれていました[6]。メインオラクルコントラクトは、寄与ソースの設定可能な最小数であるMinAggregatedSourcesを保存していました。

デプロイされた集約実装は直接読み取られていません。それでも2つの独立した手がかりが同じ方向を示しています。Pragmaのオープンソースコードは、エントリ数が偶数の場合には常に中央の2つのエントリの平均を返すこと[6]、およびこのインシデントで観測されたMEDIANの応答値が、その2つの寄与観測値の算術平均と一致していたことです。

これらのソースの背後にある数値は市場から得られたものでした。GECKOTERMINALの観測値はオンチェーンのプールから導出できる可能性があり、そのようなStarknet上の場の一つがEkuboであり、Uniswap v3に似た集中流動性を使用する分散型取引所です。流動性提供者は選択したティック範囲内に資産を配置し、スワップはプール価格をアクティブな範囲を通じて動かします。一方、アクティブな流動性のないギャップが、大きく異なる価格で配置されたポジション同士を隔てることがあります。

Nostraは、この経路を通じて取得されたNSTR価格を使用して、預け入れられた担保を評価し、口座の借入能力を計算していました。

脆弱性分析

Nostraのマネーマーケットは、その文書にNSTRの価格フィードとして記載されているコントラクト0x6838...5bf0からNSTR価格を読み取っていました[7]。このコントラクトは、MinAggregatedSourcesが1に設定された、指定されたメインオラクル0x7b05...f0abに委任していました。Pragmaは最低3つの価格ソースを推奨しており、インシデント後、3ソースの最小値が強制されていればここで受け入れられた応答は拒否されていたはずだと報告しました[3]。

したがって、2つの有効な観測値を含む応答は、設定された閾値を超えていました。2つの観測値に対するMEDIAN計算が算術平均に帰着するため、もう一方の観測値が実際の市場価格に近いままであったとしても、1つの極端なクォートが結果を大幅に歪める可能性がありました。

これは、小数スケーリングや中央値実装のエラーではなく、統合設定の弱点でした。Pragmaは、どちらの計算にも欠陥を発見しませんでした[3]。ソース閾値が不十分であったため、不十分に多様化された入力セットから正しく計算された出力が、担保価値と借入能力を決定することを許してしまいました。

攻撃分析

この攻撃は、新しく作成され、資金の薄い集中流動性プールの操作可能性に依存していました。入手可能な証拠は、攻撃者によるプールのシード投入と繰り返しの活動が、GECKOTERMINALの観測に使用されたプールに影響を与えた可能性を示していますが、プール選択の正確な因果関係は確立されていません。

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

攻撃者はまず、EkuboのNSTR/SolvBTCプールを作成し、より低い非アクティブな価格範囲に片側流動性として1.5 SolvBTCを供給しました。その後、攻撃者は通常の市場価格付近に約1,900のNSTRと0.0001514751のSolvBTCを追加し、このプールで繰り返しスワップを行いました。

次に、攻撃者は通常価格をはるかに上回る狭い範囲に190のNSTRを片側流動性として配置しました。通常の市場価格付近の流動性を除去した後、攻撃者はこの高価格ポジションの前に空の流動性ギャップを残しました。

わずか0.00000001のSolvBTCのみを含むスワップがこの空の範囲を横切り、プールをティック-6645400まで動かし、高価格ポジションの境界に到達させました。この操作されたプール価値は、その後、$99.02439975というGECKOTERMINALのNSTR/USD観測値として提出されました。

AVNUの下で提出されたもう一方の寄与観測値は、NSTRを$0.00596118と評価していました。この応答には、3つ目の設定されたソースからの観測値は見られず、これら2つの値のみが集約に到達しました[4]。

2つの値がある場合、MEDIANの応答はそれらの算術平均であり、NSTRあたり約$49.51518046でした。Nostraはこの結果として得られた評価額を受け入れ、攻撃者のNSTR預金を多額の借入に対する十分な担保として扱いました。

最初に確認された資金抽出では、攻撃者はNSTR担保を保有する別のアカウントを使用して、水増しされた評価額で約939.386010のETHを借り入れました[4]。Nostraは、完全な借入シーケンスにはSTRK、USDC、USDT、WBTC、DAIv1も含まれており、合計の借入価値は約350万ドルであったと報告しました[2]。

結論

このインシデントは、Pragmaの小数処理や集約計算のエラーではなく、Nostraの統合における不十分なオラクルソース閾値に起因していました。1つの観測値が非常に操作しやすいプールから来ていたにもかかわらず、2つのソースからの応答は有効なままでした。

Nostraは、最低でも3つ以上の寄与価格ソースを強制し、ソース数がその閾値を下回るオラクル応答は、担保評価や借入に価格を使用する前に拒否すべきです。また、担保適格性とエクスポージャー制限は、利用可能な市場流動性と、各資産の基となる価格ソースを操作するために必要な深さを反映すべきです。

参考文献

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

[2] https://x.com/nostrafinance/status/2100577538053493076

[3] https://www.pragma.build/updates/nostra-nstr-incident

[4] https://x.com/Phalcon_xyz/status/2100818035082952751

[5] https://www.pragma.build/asset/NSTR-USD?network=mainnet

[6] https://github.com/Astraly-Labs/pragma-oracle

[7] https://docs.nostra.finance/lend-and-borrow/deployed-contracts/money-market-mainnet

BlockSecについて

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

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