週刊Web3セキュリティインシデントまとめ | 2026年3月16日〜3月22日

先週（2026年3月16日〜2026年3月22日）の間、BlockSecは7件の攻撃インシデントを検知・分析しました。推定被害総額は約8,270万ドルに達します。以下の表にこれらのインシデントをまとめ、各ケースの詳細な分析を後続のセクションで説明します。

日付	インシデント	タイプ	推定被害額
2026/03/15*	Venus インシデント	ドネーション攻撃および市場操作	約215万ドル
2026/03/17	dTRINITY インシデント	精度損失（Precision Loss）	約25.7万ドル
2026/03/17	Fun.xyz インシデント	アクセス制御の不備	約8.5万ドル
2026/03/18	Keom インシデント	ビジネスロジックの欠陥	約3.5万ドル
2026/03/18	ShiMama インシデント	アクセス制御の不備	約3.5万ドル
2026/03/19	BlindBox インシデント	ビジネスロジックの欠陥	約9.9万ドル
2026/03/22	Resolv インシデント	秘密鍵の漏洩	約8,000万ドル

*Venusのインシデントは先週のレポートに含まれていなかったため、完全を期すためにここに含めています。

1. Venus インシデント

概要

2026年3月15日、BNB Chain上のVenus ProtocolのTHE (Thena) 市場が、ドネーション攻撃（寄付攻撃）と市場操作の組み合わせにより攻撃を受け、約215万ドルの不良債権が発生しました。THE市場の供給上限（サプライキャップ）はミントパスにのみ適用されていた一方、市場への直接的なトークン寄付がcashを増加させ、exchangeRate（為替レート）をインフレさせていました。攻撃者はこのインフレした担保価値を利用して流動性資産を借入し、市場価格を操作しながらより多くのTHEを獲得しました。最終的に、ポジションの強制清算が行われた後、プロトコルには不良債権が残されました。

背景

VenusはCompound V2をフォークしたレンディングプロトコルです。THE市場では、ユーザーはTHEを預け入れ、代わりにvTHEトークンを受け取ります。exchangeRateは、1単位のvTHEがいくらの基礎資産を表すかを決定するもので、その中心的な計算式は以下の通りです。

exchangeRate = (cash + borrows - reserves) / totalSupply

ここで、cashは市場の基礎トークン残高、borrowsは未払い債務の合計、reservesはプロトコルが保有する準備金、totalSupplyはvTHEの総供給量です。THE市場には、担保エクスポージャーの合計を制限することを目的とした供給上限も設定されています。

脆弱性の分析

このインシデントには、vTHE市場コントラクト（0x86e0...739f）に対する2つの複合的なベクターが含まれていました。

ドネーション攻撃

プロトコルは市場コントラクトの生のトークン残高から直接cashを導出しているため、本質的にドネーション攻撃の影響を受けやすくなっています。THEをvTHE市場コントラクトへ直接送金するとcashが増加し、結果としてexchangeRateが上昇します。攻撃者はこれを利用してexchangeRateを約3.81倍にインフレさせ、既存のvTHEポジションの担保価値を増幅させました。

市場操作

THEトークンはオンチェーン上の流動性が浅く、比較的少額の買い圧力でもスポット価格が操作されやすい状態でした。プロトコルのオラクルは基準価格から大きく乖離した価格を拒否するように設計されており、攻撃中約37分間は極端な価格を正しく却下しました。しかし、継続的な買い圧力によって最終的にTHEトークンの価格は約0.51ドル（攻撃前の約2倍）まで押し上げられ、オラクルはその価格を承認してしまいました。

これら2つのベクターは相互に強化し合いました。ドネーション攻撃によってインフレしたexchangeRateが各vTHEユニットの担保価値を増幅させ、操作されたTHE価格がさらなる借入能力を押し上げました。これらを組み合わせることで攻撃者は、供給上限の3.67倍に相当するポジションに対して約1,490万ドルの借入を行うことが可能となりました。

攻撃の分析

以下の分析は、該当の攻撃トランザクション 0xce6e3e...1f5fb0e に基づいています。

ステップ1: 攻撃者の関連ウォレットが、約9ヶ月間にわたる77回のTornadoCash関連トランザクションを通じて7,447 ETHを受信しました。そのETHをAaveに預け入れ、約992万ドルのステーブルコインを借り入れることで、供給上限1,450万THEの約84%にあたる1,220万THEのvTHEポジションを構築しました。
ステップ2: 最初の攻撃トランザクションにおいて、6つのアドレスが合計約3,600万THEをvTHE市場コントラクトに直接送金しました。また、攻撃用コントラクトは158万USDCを借入し、再預け入れを行った後、約460万THEを借入してvTHEに直接送金しました。これにより、exchangeRateは約3.81倍に上昇しました。

ステップ3: 後続のトランザクションで、攻撃者はCAKE、BNB、BTCB、USDCなどの流動性資産を借入しました。攻撃者は借入した資産で継続的にTHEを購入し、それをさらにvTHEへ寄付することで、ポジションの借入能力とTHEトークン価格の両方を上昇させるループを作成しました。

ステップ4: THEトークンの価格は約0.2ドルから上昇し、Binanceの価格ソースでは一時4ドル近くに達しました。プロトコルのオラクルは約37分間極端な価格を却下していましたが、最終的に約0.51ドルの価格を受け入れました。
ステップ5: UTC+8の20:42までに、攻撃者のポジションは約5,320万THE（供給上限の約3.67倍）に達し、総借入エクスポージャーは約1,490万ドルとなりました。
ステップ6: その後、ポジションは大規模な清算に入りました。254の清算者アドレスから8,048回の清算トランザクションを経て、約4,200万THEの担保が清算されました。売却圧力が続く中、THEトークン価格は約0.22ドルまで下落しました。清算による収益では債務を完全にカバーできず、Venusには約215万ドルの純不良債権が残りました。

結論

このインシデントにおいて新しい脆弱性は見つかりませんでした。これは、よく知られた攻撃ベクターを計画的に実行することで、各層が互いに依存し合っているプロトコルのリスクスタック全体をいかに圧倒できるかを示しています。オンチェーン上には数ヶ月前から警告の兆候があったにもかかわらず、検知と介入の間のギャップが埋められることはありませんでした。流動性を考慮したリスクパラメーター、自動化されたサーキットブレーカー、ポジションレベルの監視を通じてこのギャップを埋めることが、本インシデントが他のレンディングプロトコルに残す主要な教訓です。

詳細な分析については、当社の深掘り記事 [1] を参照してください。

参考文献

[1] https://blocksec.com/blog/venus-thena-donation-attack

2. dTRINITY インシデント

概要

2026年3月17日、Ethereum上のAave V3フォークレンディングプロトコルであるdTRINITYがdLEND市場において攻撃を受け、約25.73万ドルの損失が発生しました。根本原因は、Aave V3フォークに内在する「空の市場（Empty Market）」脆弱性です。リザーブの流動性がゼロに近い際、フラッシュローン手数料が蓄積されると liquidityIndex が極端な値まで上昇します。リザーブの会計が歪められた後、攻撃者は預け入れと引き出しのパスにおける「精度損失（Precision Loss）」を悪用し、担保価値を過大評価させてdUSDを借入し、預け入れたcbBTCを回収することで純利益を得ました。

背景

dTRINITYはステーブルコインシステムdUSDと、Aave V3をフォークしたレンディング市場dLENDを含んでいます。コアとなるL2Poolコントラクト（0xfda3...e19e84）では、各資産が独自のリザーブを持ち、リザーブの会計はスケールされた残高とリザーブのliquidityIndex（流動性指数）に基づいています。ユーザーの現在の実残高は、スケールされた残高にリザーブの正規化された収益を掛けることで算出されます。

フラッシュローンのプレミアム（手数料）は、cumulateToLiquidityIndex() を通じてリザーブ会計に追加されます。計算式は以下の通りです。

nextLiquidityIndex = ((amount / totalLiquidity) + 1) * reserve.liquidityIndex

totalLiquidity が極端に小さくなると、手数料の蓄積ごとに liquidityIndex が異常な速さで上昇する可能性があります。

脆弱性の分析

攻撃の鍵となる条件は、dLEND-cbBTC市場（0x504d...3acc）におけるリザーブがほぼ空の状態であったことでした。リザーブが1つだけのスケールされたシェアに圧縮されると、フラッシュローンの手数料は意味のある供給ベースに分散されなくなります。そのため、繰り返されるフラッシュローンによって liquidityIndex が非常に急速に上昇しました。

liquidityIndex がインフレした後、基礎資産からスケールされた値への変換は極端な四捨五入の範囲に入りました。この状態で、少額の預け入れでシェアを1単位追加できる一方、大額の引き出しでも1単位のシェアしか焼却されない状態が発生します。この非対称性を利用して、攻撃者はaCbBTC担保を過大評価させ、異なるリザーブから実際のdUSDを借入しました。これは、ヘルスチェックがプールレベルで行われ、破損したcbBTCリザーブが資産間の借入能力に直接影響したためです。

攻撃の分析

攻撃は、トランザクション 0x8d33d6...40ae7139 と 0xbec4c8...4fc33260 の2回に分けて実施されました。

トランザクション1：liquidityIndex の操作

ステップ1: Morpho Blueから cbBTC を借入。
ステップ2: dLEND-cbBTCに cbBTC を預け入れ、100のスケールされたシェアをミント。
ステップ3: シェアを99単位引き出し、残り1単位のシェアにする。これにより、dLEND-cbBTCリザーブはほぼ空のスケール供給状態に圧縮されます。
ステップ4: 8,000万単位の cbBTC（つまり0.8 cbBTC）をdLEND-cbBTCのaTokenに直接送金。
ステップ5: 150回の Pool.flashLoan() 呼び出しを実行し、プレミアムをリザーブ会計に蓄積させ、liquidityIndex を 6,226,621,999,999,999,999,999,999,979,728,276 まで引き上げる。

ステップ6: 預け入れと引き出しのサイクルを繰り返し、リザーブ内の残りのキャッシュを抽出。
ステップ7: フラッシュローンを返済。

トランザクション2：利益の確定

ステップ1: 再びMorpho Blueから cbBTC を借入。
ステップ2: 約7.72 cbBTC を、既に操作済みのリザーブに預け入れ、過大評価された aCbBTC 担保ポジションを構築。

ステップ3: 過大評価された担保を利用して、dLEND-dUSD市場から 257,328 dUSD を借入。

ステップ4: 預け入れと引き出しのサイクルを繰り返すことで、cbBTC の抽出を継続。

ステップ5: Morphoのフラッシュローンを返済し、借入した dUSD を攻撃者のEOAに転送。

結論

このインシデントは、Aave V3フォーク全体で文書化されている「空の市場攻撃」の事例です。このパターンは複数のプロトコルで発生しており、対策も確立されています。リザーブ初期化時に最低供給しきい値を設けることで、インデックスの成長が制御不能になる状態を防ぐことができます。Aave V3をフォークするプロトコルは、リザーブのブートストラップ（立ち上げ）を重要なオペレーションとして扱い、デプロイ時に意味のある流動性をロックするよう確保すべきであり、デポジットの流れによってインデックスが安定することをあてにすべきではありません。

3. Fun.xyz インシデント

概要

2026年3月17日、Polygon上のチェックアウトインフラプロトコルであるFun.xyzに対して攻撃が行われ、約8.57万ドルの被害が発生しました。根本原因は、レガシーの CheckoutPool が bridge() 関数をアクセス制御なしで公開しており、かつブリッジのコールデータを意図した受信者に結びつけていなかったことにあります。この脆弱性により、攻撃者は実行先を信頼された決済パスへリダイレクトさせ、攻撃者がコントロールするスマートアカウントへ資金を転送することが可能となりました。

背景

CheckoutPool は、Fun.xyzのチェックアウトインフラにおける中核的な決済コントラクトです。通常のフローでは、ユーザーが deposit() を通じてチェックアウトを作成し、信頼されたオペレーターが bridge() や execute() などの決済パスを通じてそれを進行させます。ブリッジ操作において、bridge() は呼び出し元が提供した bridgeParams.target と bridgeParams.callData に基づいて外部呼び出しを実行します。

脆弱性の分析

根本原因は、レガシーの CheckoutPool（0x1304...2ec01a）が、適切なアクセス制御なしに bridge() 関数を通じて機密性の高い決済ルーティングパスを公開し、かつ外部から提供されたブリッジのコールデータを意図した受信者に対して検証していなかったことにあります。具体的には以下の通りです。

レガシーの実装では bridge() に対して onlyOperator 修飾子を強制しておらず、deposit() を通じてチェックアウトを作成した後であれば、誰でも外部から関数を呼び出すことが可能でした。
bridge() は、呼び出し元が提供した bridgeParams を _bridgeToRecipient() に渡していました。これは、チェックアウト実績に対して受信者の検証を行わずに外部呼び出しを実行していました。

このエクスプロイトを実用可能にしたのは、追加の運用上の状況でした。エクスプロイト発生時に、レガシーの CheckoutPool は CheckoutPaymaster 内で依然としてオペレーター権限を保持していました。これにより、細工された bridge() の呼び出しが CheckoutPaymaster.activateAndCall() に到達し、その後新しい CheckoutPool.execute() パスが呼び出され、資金が攻撃者のコントロールするアドレスに転送されたのです。

攻撃の分析

以下の分析は、該当の攻撃トランザクション 0x957bcf...1f4f5a に基づいています。

ステップ1: ERC-4337 スマートアカウント 0xb648 を作成し、外部 UserOperation における送信者（sender）とペイマスター（paymaster）の両方に指定。
ステップ2: レガシーと新しい両方の CheckoutPool で deposit() を呼び出し、新しい CheckoutPool にて決済額 85,730 USDC のチェックアウトレコードを作成。
ステップ3: レガシーの CheckoutPool で、悪意のある bridgeParams を用いて bridge() を呼び出す。bridgeParams.target を CheckoutPaymaster に設定し、bridgeParams.callData を外部 UserOperation を内部ペイロードとして運ぶ activateAndCall() への呼び出しとしてエンコード。

ステップ4: 新しい CheckoutPool（0x1929...0215）において execute() に到達。これにより、外部 UserOperation 内で ops[0].sender として指定されたアドレス 0xb648 へ 85,730 USDC が転送されます。

ステップ5: EntryPoint.handleOps() に突入：0xb648 が送信者とペイマスターの両方を務めるため、アカウント検証とペイマスター検証の両方が攻撃者のコントロール下に留まり、攻撃者は 85,730 USDC の利益を得ることができました。

結論

このインシデントは、レガシーの CheckoutPool がその bridge() パスにおいてアクセス制御とコールデータ・受信者の紐付けが欠如していたことが原因で、約8.57万ドルの損失となりました。同様のインシデントを防ぐため、プロトコルは機密性の高いルーティングや決済フロー全体で厳格なアクセス制御を強制し、外部から提供されたペイロードがプロトコル由来の受信者と一致していることを保証し、パッチ済みの代替品がデプロイされた後は信頼関係にある古いコントラクトを削除するべきです。

4. Keom インシデント

概要

2026年3月18日、Polygon zkEVM上のCompound V2フォークレンディングプロトコルであるKeomが約3.5万ドルの被害を受けました。根本原因は、redeemUnderlying() から呼び出される redeemFresh() 内の欠陥ある会計ロジックでした。この関数はシェアの削減量をユーザーの実際の残高までキャップ（上限設定）しましたが、それに応じて基礎資産の引き出し量を再計算しませんでした。この不一致により、攻撃者はシェアが許可する以上の多額の資産を引き出すことが可能となりました。

背景

KeomはCompound V2をフォークしたレンディングプロトコルです。ユーザーは市場に ETH を供給し、代わりに kETH を受け取ります。ユーザーが償還（redeem）を行う際、プロトコルは現在の為替レートを使用して kETH シェアを ETH に変換します。このプロトコルには、シェア量に基づいて償還する redeem() と、希望する基礎資産量に基づいて償還する redeemUnderlying() の2つの償還エントリーポイントがあります。

脆弱性の分析

欠陥は、redeemUnderlying() から呼び出される kETH 市場（0x4c6e...0403）の redeemFresh() にあります。ユーザーが制御する redeemAmountIn は最初に redeemAmount に代入され、続いて現在の為替レートを介して redeemTokens の計算に使用されます。もし redeemTokens が償還者の残高を超えた場合、関数はそれを accountTokens[redeemer] にキャップします。しかし、このキャップ後に redeemAmount は再計算されず、元の redeemAmountIn と等しいままです。これにより、償還者は対応するシェアのわずかな一部を焼却するだけで、redeemAmount 全額の基礎資産を引き出すことができてしまいます。

以下のコードスニペットに示すように、redeemFresh() は redeemAllowed() を通じてヘルスチェックも行います。Compound V2の設計では、redeemAllowed() は markets[cToken].accountMembership[redeemer] を確認し、そのアカウントが当該 cToken 市場に参加している場合にのみ流動性チェックを呼び出します。それ以外の場合、チェックは完全にスキップされます。redeemAmountIn は攻撃者が制御可能で任意に大きく設定できるため、もし kETH が依然として担保としてカウントされるのであれば流動性チェックは失敗するはずです。つまり、この会計上の欠陥単体では、ヘルスチェックを最初に回避しない限り直接的な悪用はできません。

攻撃の分析

以下の分析は、該当の攻撃トランザクション 0x4ccde7...03d9dfd8 に基づいています。

ステップ1: わずか 0.001 ETH で mint() を呼び出し、最低限の kETH 残高を取得。

ステップ2: exitMarket() を呼び出し、アカウントの kETH 市場への参加状態を解除。これにより、上記の脆弱性分析で説明した通り、redeemAllowed() が流動性チェックを完全にスキップするようにします。
ステップ3: redeemUnderlying() を呼び出して市場の ETH 残高を全額（約38.6 ETH）引き出し、欠陥ある会計処理を悪用して市場から ETH を枯渇させます。

結論

このインシデントは、redeemTokens をユーザーの実際の残高にキャップした後で redeemAmount を再計算しなかった会計上の脆弱性が原因であり、約3.5万ドルの損失をもたらしました。償還ロジックは、シェアと基礎資産の不変性を維持するために、キャップや調整が行われた後は必ず全ての依存値を再計算しなければなりません。Compound V2のフォークは、他のデリバティブにも同様の欠陥が存在する可能性があるため、このパスを慎重にレビューする必要があります。

5. ShiMama インシデント

概要

2026年3月18日、BNB Chain上のデフレ型トークンプロトコルであるShiMamaが約3.5万ドルの被害を受けました。根本原因は関数 executePairBurn() におけるアクセス制御の欠如であり、これが任意のユーザーによるペアリザーブの引き出しと焼却のトリガーを許し、価格操作を可能にしました。

背景

ShiMama プロトコルには、AMM（自動マーケットメイカー）ペアからトークンを引き出して焼却することを目的としたオンチェーンのデフレメカニズムが含まれています。このメカニズムは ShiMama プロトコルと ShiMama トークン全体に実装されています。ShiMama プロトコルの関数 executePairBurn() は、呼び出し元が提供した referenceIn パラメーターから引き出し量を以下のように計算します。

pullAmt = referenceIn * pairBurnBpOnSell / 10_000

その後、ShiMama トークンの forcePullFromPair() を呼び出し、続いて pair.sync() を実行して、引き出されたトークンを焼却します。

脆弱性の分析

根本原因は、ShiMamaProtocol コントラクト（0x5049...0b49a）における executePairBurn() のアクセス制御の欠如です。この関数は制限なしで外部から呼び出し可能であるため、ユーザーは誰でも機密性の高いリザーブの移動とペアの同期をトリガーできます。referenceIn も呼び出し元が操作可能であり、実際の売却額には結びついていません。ShiMamaToken.forcePullFromPair() では、プロトコルは制限なく直接 Pancake ペアから残高を移動させることができるため、任意の準備金除去と即時の同期を可能にし、結果としてスポット価格の操作を実現しています。

攻撃の分析

以下の分析は、該当の攻撃トランザクション 0x13959b...3c20e001 に基づいています。

ステップ1: Moolah フラッシュローンから WBNB を借入。
ステップ2: 前のトランザクションであらかじめ調達しておいた 30.78e18 ShiMama を攻撃コントラクトへ転送。Pancake ペアからの直接的な ShiMama 購入は無効化されていたため、攻撃者は攻撃前に ShiMama プロトコルで流動性を提供および引き出しを行って、ShiMama を調達しました。
ステップ3: executePairBurn() を呼び出し、1,311,349,143.96 ShiMama トークンを Pancake ペアから引き出して焼却し、事実上 ShiMama 価格をインフレさせました。
ステップ4: 攻撃者はインフレした価格で、PancakeSwap 上にて 30.78e18 ShiMama を 52.98e18 WBNB と交換。
ステップ5: フラッシュローンを返済し、52.98 WBNB を純利益として残しました。

結論

このインシデントは executePairBurn() に対するアクセス制御がなかったことが原因で、プールリザーブを改変するための不正な経路が露呈しました。準備金を変更する関数は経済的に非常に敏感であり、厳格に権限管理が行われなければなりません。呼び出し元が制御可能な入力は、リザーブ抽出の増幅を防ぐためにプロトコルが導出する値に紐付ける必要があります。

6. BlindBox インシデント

概要

2026年3月19日、BNB Chain上のGameFiベッティングプロトコルであるBlindBoxが約9.9万ドルの被害を受けました。根本原因は弱い乱数であり、これにより攻撃者は結果を予測し、勝率100%を達成することが可能でした。さらに、getTwapPrice() は真の時間加重平均ではなく操作可能なスポット価格に依存していたため、攻撃者は事前にプール価格をインフレさせ、プロトコルの意図した制限を超えた賭けを行うことができました。

背景

BlindBox はユーザーが ATM トークンをデッドアドレスに転送することで賭けを行う GameFi プロトコルです。プロトコルは、後のブロックハッシュのパリティ（偶奇）に基づいて結果を判定します。勝った場合、BlindBox はデッドアドレスのバンクロールから元の ATM 額の1.95倍を配当します。プロトコルは getTwapPrice() を使用して、各賭けのサイズを制限しています。

脆弱性の分析

BlindBox コントラクト（0x1F83...734c59）には2つの脆弱性があります。

弱い乱数: 決済時間が256ブロックを超えると、blockhash(bet.blockNum + 2) はゼロを返します。プロトコルはその際、block.prevrandao、betId、block.timestamp から導出される乱数にフォールバックします。これらの入力はトランザクションを送信する前にオフチェーンでシミュレーション可能なため、攻撃者は計算結果が有利な場合のみ settle() を呼び出すことで、確定的な勝利を得ることができました。

操作可能な価格制限: プロトコルは賭けのサイズを制限するために getTwapPrice() を使用していますが、この関数は真の時間加重平均価格を実装していません。代わりに ATM/USDT プールのスポット価格を読み取ります。これにより、攻撃者は賭けを行う前にプール価格を操作することで、制限をバイパスできるようになっていました。

攻撃の分析

以下のステップは攻撃パターンを示しています。ステップ2と3でペアのシーケンスが形成されており（例：betId=5,284）、攻撃者は利益を蓄積するためにこのペアを何度も繰り返しました。

ステップ1: ATM/USDT プールを操作し、ATM スポット価格をインフレさせることで、次のステップで getTwapPrice() がより大きな賭けサイズを許可するようにする。
ステップ2: インフレした許容量の ATM 額をデッドアドレスに転送して、多額の賭けを行う（例：0x4be049...3af12c）。

ステップ3: 256ブロック以上経過して blockhash がゼロを返し、フォールバックパスが作動するまで待つ。攻撃者はオフチェーンで結果をシミュレーションし、計算結果が有利な場合のみ（例えば 0x68eedc...718ce8 のように）settle() を呼び出す。

結論

このインシデントは、予測可能な乱数と、TWAP入力として操作可能なスポット価格が組み合わさったことが原因であり、約9.9万ドルの損失となりました。同様のリスクを軽減するため、プロトコルは blockhash ウィンドウが切れた後に予測可能となる決済パスを削除し、短期間の準備金操作に耐性のある価格ソースを getTwapPrice() の代わりに導入するべきです。

7. Resolv インシデント

概要

2026年3月22日、Ethereum上のステーブルコインプロトコルであるResolvにおいて、インフラ鍵の侵害が発生し、権限を要するスワップ完了ロジックの不正実行が可能となりました。このインシデントにおいて攻撃者はこの権限ある関数を悪用し、8,000万以上の担保なき USR をミントしました。影響は直接的なミントイベントを超えて拡大しました。Resolv資産が担保として使用されていた他のレンディングプロトコルへと波及し、連鎖的な影響（コンタージョン）を引き起こしたのです。

背景

Resolv は USR の発行を担保付きスワップ決済に依存するステーブルコインプロトコルです。completeSwap() -> mint() -> transfer() というスワップ完了パイプラインは USR の循環供給量に直接影響を与えるため、承認の整合性と担保の整合性の両方に依存します。正常な動作では、Resolv コントラクト（0xa27a...5861）における completeSwap() は、対応する担保預け入れが検証された後、権限あるインフラ鍵（コード内では SERVICE_ROLE と命名）のみが呼び出し可能です。

脆弱性の分析

このインシデントは、権限ある鍵が侵害され、信頼された決済ロジックが呼び出されたことで、同等の担保流入がないまま USR のミントパスに到達したことが原因です。攻撃者が権限ある署名権限を掌握すると、completeSwap() パスはオンチェーンでのミント前提条件の強制を一切行わなくなりました。担保検証は完全にオフチェーンでの承認に依存していたのです。これにより、コントロールプレーンの侵害が直接的に供給の整合性の欠如へと変換されました。

攻撃の分析

ステップ1: エクスプロイトの前、攻撃者はトランザクション 0x590b5c...de732c89 でスワップリクエストを送信し、後続の悪意のあるスワップ完了に必要な状態を準備しました。
ステップ2: 侵害された権限鍵を使用して、攻撃者は completeSwap() を呼び出し、3つのトランザクションを経て合計 8,000万以上の USR をミントしました：0xfe37f2...dc33743、0x41b6b9...db1f18f、0x7f9143...53a931d。

結論

このインシデントは、ステーブルコインの安全性が信頼されたオペレーターの役割だけでなく、確固としたオンチェーンでのミントの前提条件に依存していることを浮き彫りにしました。特に、このインシデントの影響は8,000万ドルの不正な USR ミントを遥かに超えて拡大しました。Resolv 資産は複数のレンディングプロトコルで担保として広く使用されていたため、デペグ（価格乖離）がより広範な連鎖倒産を引き起こしました。Chaos Labs が報告したように、自動イールド運用を行っていたオンチェーンのキュレーターにはリアルタイムなリスク管理が欠如しており、既に機能不全に陥った市場へ新鮮な資本を投入し続けてしまいました。局所的な悪用から始まったものが、瞬く間にプロトコル間を越えて伝染し、レンディングプロトコルに数百万ドルの不良債権をもたらすイベントに発展したのです。

BlockSec について

BlockSec は、フルスタックのブロックチェーンセキュリティおよび暗号資産コンプライアンスプロバイダーです。スマートコントラクト、ブロックチェーン、ウォレットなどのコード監査、リアルタイムの攻撃迎撃、インシデント分析、不正資金の追跡、AML/CFT義務への対応など、プロトコルやプラットフォームのライフサイクル全般を通じて、お客様を支援する製品とサービスを構築しています。

BlockSecは名だたる会議で複数のブロックチェーンセキュリティ論文を発表し、DeFiアプリケーションのゼロデイ脆弱性を複数報告し、複数のハッキングを阻止して2,000万ドル以上の救済に成功し、数十億ドル相当の暗号資産を保護してきました。

公式サイト: https://blocksec.com/
公式Twitter: https://twitter.com/BlockSecTeam
🔗 BlockSec 監査サービス : リクエストを送信
🔗 Phalcon セキュリティ APP: デモを予約
🔗 Phalcon コンプライアンス