〜3600万ドルの損失：Summer.fi、Bonzo Lendなど｜BlockSec週刊

先週（2026/07/06 - 2026/07/12）、合計3件の注目すべきセキュリティインシデントが確認され、約3,629万ドルの損失が発生しました。

• Summer.fi：多層ボールトプロトコルにおいて、完全にオフボードされていない下流コンポーネントが上位レベルのシェア価格をサイレントに破損させる可能性があることを示しているため選択しました。これは、障害のあるポジションが悪用可能になる前にデコミッションを完了することの重要性を浮き彫りにしています。
• Bonzo Lend：オラクル層におけるBLS検証の微妙な欠陥が署名セキュリティを完全にバイパスし、偽造された価格ルートと、影響を受けた検証者に依存するプロトコルへの体系的なリスクにつながることを示しているため選択しました。

今週のハイライト：Summer.fi

このインシデントは、多層ボールトプロトコルにおいて、完全にオフボードされていない下流コンポーネントが上位レベルのシェア価格をサイレントに破損させる可能性があることを示しているためハイライトしています。このパターンは、すべての寄与元がまだ正常であることを検証せずにネストされた外部ソースから値を集約するあらゆるシステムに広く当てはまります。

2026年7月6日、EthereumのSummer.fi FleetCommanderボールトが約604万ドルの被害を受けました [1][2]。根本原因は、Summer.fiのFleetCommanderが、オフボーディングのためにキャップされたものの、アクティブセットからまだ削除されていない戦略コンポーネント（Arkと呼ばれる）をtotalAssets()の計算に含め続けていたことです。攻撃者は、Arkが依然としてパーに近い価格をつけていた大量の古くて過大評価されたvgUSDCトークンを蓄積し、それらを直接Arkに転送してFleetCommanderのシェア価格を膨らませ、その水増しされた価格で償還しました。

背景

Summer.fiは、ボールト・オブ・ボールトアーキテクチャ上に構築されたDeFiイールドアグリゲーターです。ユーザーはFleetCommanderと呼ばれるERC-4626親ボールトに資産を預け、FleetCommanderはArksと呼ばれる一連の戦略アダプターを通じてさまざまな基盤となるレンディングおよびイールドプロトコルに資金をルーティングします。FleetCommanderの総資産は各Arkの自己申告値から集計され、ユーザーはこの集計評価に基づいていつでもシェアを償還できます。

基盤となるイールドソースの一つはMorphoです。FleetCommanderはArkを介してMorpho Vaultに資金を預け、そのボールトで保有するシェアによって自身の価値を評価します。ユーザーがFleetCommanderのシェアを償還する際、親ボールトのキャッシュバッファが不足している場合、基盤となるボールトからスタックを通じて資金を引き出します：

ユーザーがFleetCommanderシェアを償還
   | (1) ユーザーのシェアをバーン
   v
FleetCommander
   | (2) まずバッファから支払い、その後ArkSから引き出す
   v
Ark
   | (3) 現金を調達するために、基盤となるボールトで自身のシェアを償還
   v
Morpho Vault
     (4) 支払うために、基盤となるマーケットから引き出す

各Arkは基盤となるボールトでの自身のトークン残高を照会し、そのシェアを資産に変換することでtotalAssets()を計算します。これらのシェアは標準的なERC-20トークンであるため、誰でもFleetCommanderのデポジットフローを経ずに追加のシェアを直接Arkに転送できます。

脆弱性の分析

影響を受けたFleetCommanderは、LowerRisk USDCボールト（0x98C4...cF17）とHigherRisk USDCボールト（0xE9cD...cB06）です。操作されたSilo Varlamore Arkは0x61d7...76c2です。

悪用の土台となった2つの条件：

1. 古くて過大評価された資産。 2025年11月にStream Financeが崩壊し [3]、そのイールドトークンxUSDが75%以上の価値を失った後、xUSDに担保されたポジションを保有していたSilo「Varlamore USDC Growth」ボールトはほぼ回収不可能になりました。しかし、ボールトのオンチェーン会計はこの損失を反映しませんでした：vgUSDCトークンは、基盤となるUSDCが立ち往生したままであったにもかかわらず、convertToAssets()を通じてパーに近い価値を報告し続けました。

2. 部分的に削除されたArk。 この障害のあるエクスポージャーを保有するArkは、デポジットキャップを0に設定してオフボードされていました。しかし、キャップをゼロにすることはFleetCommanderを通じた新規デポジットをブロックするだけです。ArkをtotalAssets()の計算から削除するものではありません。

Arkはvault.balanceOf(address(this))を呼び出し、次にvault.convertToAssets(shares)を呼び出すことでtotalAssets()を計算します。これらのシェアは転送可能なERC-20トークンであるため、誰でも古くて過大評価されたvgUSDCをArkに直接転送でき、新しいシェアが発行されることなく、実際に引き出し可能な流動性が追加されることもなく、ArkのtotalAssets()を膨らませます。この水増しはFleetCommanderのシェア価格に伝播します。

攻撃の分析

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

• ステップ1：攻撃者は過去3ヶ月にわたり、複数のウォレットを通じて約190.8億vgUSDCを蓄積し、悪用の直前に攻撃コントラクトに統合しました。

• ステップ2：攻撃者はMorpho Blueから1,000,000USDTのフラッシュローンを取り、次に65,419,171USDCのフラッシュローンをネストして攻撃に資金を提供しました。

• ステップ3：攻撃者は複数のMorpho V2ボールトに対してforceDeallocate()を呼び出し、4,318,535USDCをMorpho Blueマーケットからボールトのアイドル残高に引き戻しました。これにより、後のステップで水増しされた償還を支払うための十分な流動資本が確保されました。

• ステップ4：攻撃者はUniswap V4で20,000USDTを約68,421xUSDにスワップし、そのxUSDをBalancer V3で約4億7,627万vgUSDCにスワップしました。これにより、最小限の実際のコストで追加の古いトークンが蓄積されました。

• ステップ5：攻撃者はFleetCommander LVUSDCに64,828,534USDCを預け、60,787,156シェアを受け取りました。

• ステップ6：攻撃者は約195.5億vgUSDCシェアをvgUSDC Arkに直接転送しました。ArkのtotalAssets()はシェアがどのように届いたかに関わらず保有するすべてのシェアをカウントするため、これによりArkの報告値が水増しされ、FleetCommanderのtotalAssets()も対応して水増しされました。

• ステップ7：攻撃者は60,766,209 FleetCommanderシェアを70,959,584USDCで償還し、水増しされたシェア価格と元の預け入れの差額から利益を得ました。

• ステップ8：同じアトミックトランザクション内で、攻撃者はHigherRisk USDC FleetCommanderにも同様の水増しを適用しました。HigherRiskの部分ではvgUSDCではなくHigherRisk Term ArkにTermシェアを寄付しましたが、根本的なメカニズムは同じでした：寄付によるtotalAssets()の水増し、その後水増しされた価格での償還。両ボールト合計の利益は約604万ドルでした。

結論

これはコードのバグではなく、運用上の失敗によるシェア価格水増し攻撃でした。Stream Financeの崩壊によって損傷したSilo Arkは、オフボード中にもかかわらずFleetCommanderのtotalAssets()に含まれたままでした [2]。攻撃者は安価に蓄積した古くて過大評価されたvgUSDCをこのArkに寄付し、シェア価格を水増しして、他のデポジター負担で預けた額以上を償還しました。

デポジットキャップをゼロにすることはArkをオフボードするものではありません。多層ボールトシステムでは、totalAssets()はリタイアしたポジションを除外する必要があり、保有資産は古いオンチェーン引用ではなく実現可能な価値で評価されるべきです。オフボード中のコンポーネントは、水増しベクターとして機能する可能性がある前に、集計評価から完全に削除されるべきです。

参考文献

• [1] X上のPhalconアラート
• [2] Summer.fi コミュニティコールまとめ
• [3] Stream Financeが9,300万ドルの損失に直面（CoinDesk）

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

Bonzo Lend

2026年7月11日、HederaのレンディングプロトコルであるBonzo Lendは、約905万ドルの損失を被りました [1]。攻撃者がSAUCE価格フィードのために、プロトコルのサードパーティ価格フィードプロバイダーであるSupraに偽造されたオラクルアップデートを提出したことが原因です。オラクル検証者はゼロ署名の証明を受け入れ、水増しされたSAUCE/WHBAR価格をオンチェーンに書き込みました。Bonzo Lendはその後、操作されたフィードを読み取り、攻撃者が投稿したSAUCE担保の実際の価値をはるかに超える資産の借り入れを許可しました。

背景

Bonzo LendはHederaのレンディングプロトコルです。マーケット会計は、SAUCEなどのエコシステム資産についてサードパーティオラクルネットワークであるSupraを含む外部価格フィードに依存しています。Bonzo Lend自体はすべてのオラクル委員会署名を認証するわけではなく、オラクルのオンチェーンフィードにすでに保存されている最新の値を読み取り、担保価値と借入能力を計算する際にその値を使用します。

Supraのプル型オラクルアップデートパスは、フィードデータをストレージに書き込む前に送信されたルートを検証します。関連するコードパスでは、verifyOracleProofV2()が送信されたオラクルデータを反復処理し、merkleSetにまだキャッシュされていないルートに対してrequireRootVerified()を呼び出し、Merkleリーフを検証してから、packData()を通じて新しいフィードラウンドを書き込みます。

if (merkleSet.contains(oracle.data[i].root)) {
    continue;
}
requireRootVerified(oracle.data[i].root, oracle.data[i].sigs, oracle.data[i].committee_id);
if (!merkleSet.set(oracle.data[i].root)) {
    revert RootIsZero();
}

フィードアップデートのセキュリティは、requireRootVerified()が設定されたオラクル委員会によって真に署名されていないルートを拒否することに依存しています。

脆弱性の分析

バグのあるコントラクトはSupraオラクル検証者（0.0.4323006）です。

根本原因は、上流のSupraオラクル検証者における無効なBLS検証パスでした。悪用トランザクションは、委員会ID 2とゼロ化された署名値[0, 0]を持つペア425（SAUCE/WHBAR）の価格アップデートを提出しました。

通常のBLSチェックでは、検証者はペアリングプリコンパイルを呼び出す前に、署名と公開鍵がゼロでなく、曲線上にあり、正しいサブグループにあることを検証する必要があります。脆弱な検証者はゼロ署名点とゼロ委員会公開鍵点からペアリングチェックを構築しました。Hederaのペアリングプリコンパイルはtrueを返しましたが、それは実際の委員会署名が存在したからではなく、単位元点のペアリング積が数学的に有効だからです。

検証者は入力の有効性をチェックする必要があります。プリコンパイルはペアリング方程式のみをチェックします。ペアリング前のゼロ点拒否を見逃したことで、オラクルは偽造されたルートを受け入れ、操作された価格データをストレージに通過させることを許可しました。

function requireHashVerified_V2(
    bytes32 _message,
    uint256[2] calldata _signature,
    uint256 committee_id
) public view {
    bool callSuccess;
    bool checkSuccess;
    (checkSuccess, callSuccess) = BLS.verifySingle(
        _signature,
        committee_public_key[committee_id],
        BLS.hashToPoint(domain, abi.encode(_message)),
        blsPrecompileGasCost
    );
    if (!callSuccess) {
        revert BLSInvalidPublicKeyorSignaturePoints();
    }
    if (!checkSuccess) {
        revert BLSIncorrectInputMessaage();
    }
}

攻撃の分析

以下の分析は、トランザクション0.0.995584-1783731093-686041919に基づいています。

• ステップ1：攻撃者はBonzo Lendに担保として250SAUCEを預けました。

• ステップ2：攻撃者はSupraのプル型オラクルコントラクトに悪意のあるオラクルアップデートを送信しました。アップデートは上記のゼロ化されたBLS署名証明を使用しながら、SAUCE価格を極めて水増しされた値に設定しました。

• ステップ3：verifyOracleProofV2()は、requireRootVerified()が成功して返った後、送信されたルートを受け入れました。関数はMerkleリーフデータを検証し、新しいフィードラウンドに対してpackData()を呼び出し、操作されたSAUCE/WHBAR値が最新の保存されたオラクル値になりました。

• ステップ4：Bonzo Lendはオラクルから最新のSAUCE価格を読み取りました。保存されたフィード値はすでに水増しされていたため、プロトコルは攻撃者の250SAUCE担保を市場価値をはるかに超える価値があると計算しました。

• ステップ5：攻撃者は水増しされた担保価値に対して約660万USDCと3,450万WHBARを借り入れました。異常な価格は、後の正当なオラクルアップデートがSAUCEを通常の範囲に戻すまで有効なままでした。

結論

このインシデントはレンディングプールの会計バグではなく、オラクル検証の失敗でした。攻撃者はSAUCEマーケットを操作する必要も、Bonzo Lendの内部担保チェックをバイパスする必要もありませんでした。偽造された価格は上流のSupraオラクル検証者によって受け入れられ、フィードに書き込まれ、Bonzo Lendは通常の価格読み取りパスを通じてそれを消費しました。

外部フィードを消費するプロトコルは、オラクル検証パス全体のセキュリティ前提を継承します。BLSベースのオラクルアップデートでは、ペアリングプリコンパイルが呼び出される前にゼロ点を拒否する必要があります。暗号層での入力検証は任意ではありません。ペアリング方程式の数学的有効性は、基盤となる署名の真正性を意味しません。

参考文献

• [1] Bonzo Financeインシデントレポート

• Phalcon Securityを始める

  あらゆる脅威を検出し、重要なアラートを発し、攻撃をブロックする。

  今すぐ無料で試す