過去1週間(2026年3月16日~2026年3月22日)、BlockSecは7件の攻撃インシデントを検出し分析しました。総推定損失額は約8,270万ドルです。下の表にこれらのインシデントの概要を示し、各ケースの詳細な分析は以下のサブセクションで提供します。
| 日付 | インシデント | タイプ | 推定損失額 |
|---|---|---|---|
| 2026/03/15* | Venus Incident | Donation Attack & Market Manipulation | ~$2.15M |
| 2026/03/17 | dTRINITY Incident | Precision Loss | ~$257K |
| 2026/03/17 | Fun.xyz Incident | Access Control Issue | ~$85K |
| 2026/03/18 | Keom Incident | Business Logic Flaw | ~$35K |
| 2026/03/18 | ShiMama Incident | Access Control Issue | ~$35K |
| 2026/03/19 | BlindBox Incident | Business Logic Flaw | ~$99K |
| 2026/03/22 | Resolv Incident | Compromised Private Key | ~$80M |
*Venusインシデントは前週のレポートではカバーされていませんが、網羅性のためにここに含めています。
1. Venus Incident
概要
2026年3月15日、Venus ProtocolのBNB Chain上のTHE(Thena)市場で、**寄付攻撃(donation attack)と市場操作(market manipulation)**が組み合わさり、約215万ドルの不良債務が発生しました。THE市場の供給上限はミントパスにのみ適用され、直接のトークン寄付は依然としてcashを増加させ、exchangeRateをインフレさせました。攻撃者はその後、このインフレした担保価値を利用して流動性資産を借り入れ、THEトークンの市場価格を押し上げながら、より多くのTHEを獲得しました。最終的に、ポジションの強制清算後にプロトコルに不良債務を残しました。
背景
VenusはCompound V2のフォークされたレンディングプロトコルです。THE市場では、ユーザーはTHEを預け入れ、vTHEトークンを受け取ります。exchangeRateは、各vTHEが市場の裏付け資産のどれだけを表すかを決定し、その中心的な公式は次のとおりです。
exchangeRate = (cash + borrows - reserves) / totalSupply
ここで、cashは市場の裏付けトークン残高、borrowsは総未払債務、reservesはプロトコル所有の準備金、totalSupplyは総vTHE供給量です。THE市場には、総担保エクスポージャーを制限することを目的とした供給上限もあります。
脆弱性分析
このインシデントには、vTHE市場コントラクト(0x86e0...739f)に対する2つの増幅ベクトルが含まれていました。
寄付攻撃 (Donation Attack)
プロトコルは、市場コントラクトの生のトークン残高から直接cashを導出するため、寄付攻撃に対して本質的に脆弱です。THEをvTHE市場コントラクトに直接転送すると、cashが増加し、したがってexchangeRateも増加します。攻撃者はこれを悪用してexchangeRateを約3.81倍にインフレさせ、既存のvTHEポジションの担保価値を増幅させました。
市場操作 (Market Manipulation)
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,220万THEのvTHEポジション(1,450万THEの供給上限の約84%)を構築しました。 -
ステップ2:最初の攻撃トランザクションで、6つのアドレスが約3,600万
THEを直接vTHE市場コントラクトに転送しました。攻撃コントラクトは158万USDCを借り入れ、それを再供給し、その後約460万THEを借り入れて直接vTHEに転送しました。これによりexchangeRateが約3.81倍に上昇しました。

- ステップ3:その後のトランザクションで、攻撃者は
CAKE、BNB、BTCB、USDCなどの流動性資産を借入ました。攻撃者は借入資産でTHEを買い続け、より多くの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ドルまで下落しました。清算 proceedsは全債務をカバーできず、Venusに約215万ドルの純不良債務が残りました。
結論
このインシデントでは、新しい脆弱性は明らかになりませんでした。それは、各レイヤーが他のレイヤーが保持することを想定している場合に、よく知られた攻撃ベクトルが組織的に実行されると、プロトコルのリスクスタック全体を圧倒できることを示しました。警告信号は数ヶ月前からオンチェーンで可視化されていましたが、検出と介入の間のギャップは未解決のままでした。流動性を考慮したリスクパラメータ、自動化されたサーキットブレーカー、およびポジションレベルの監視を通じてそのギャップを埋めることが、このインシデントが他のレンディングプロトコルに残す中心的な教訓です。
詳細な分析については、弊社のディープダイブ投稿[1]をご覧ください。
参考文献
2. dTRINITY Incident
概要
2026年3月17日、Ethereum上のAave V3フォークレンディングプロトコルであるdTRINITYが、そのdLENDレンディング市場を通じて不正利用され、約257.3Kドルの損失が発生しました。根本原因は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を借りることができました。これは、ヘルスチェックがPoolレベルで実行され、破損したcbBTCリザーブがクロスアセットの借入能力に直接影響を与えたためです。
攻撃分析
エクスプロイトは2つのトランザクションで構成されました:0x8d33d6...40ae7139および0xbec4c8...4fc33260。
トランザクション1: liquidityIndex 操作
-
ステップ1:Morpho Blueから
cbBTCを借入ます。 -
ステップ2:
cbBTCをdLEND-cbBTCに預け入れ、100スケーリングシェアをミントします。 -
ステップ3:99ユニットのシェアを引き出し、1シェアのみが残るようにします。これにより、dLEND-cbBTCリザーブをほぼ空のスケーリング供給状態に圧縮します。
-
ステップ4:80,000,000ユニットの
cbBTC(つまり0.8cbBTC)をdLEND-cbBTC aTokenに直接転送します。 -
ステップ5:150回の
Pool.flashLoan()呼び出しを実行して、プレミアムをリザーブ会計に蓄積し、liquidityIndexを6,226,621,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 Incident
概要
2026年3月17日、Polygon上のチェックアウトインフラプロトコルであるFun.xyzが、約85.7Kドルで不正利用されました。根本原因は、レガシー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で送信者とペイマスターの両方として指定します。
-
ステップ2:レガシーCheckoutPoolと新しいCheckoutPoolの両方で
deposit()を呼び出し、新しいCheckoutPoolに決済金額85,730USDCのチェックアウトレコードを作成します。 -
ステップ3:レガシーCheckoutPoolで
bridge()を、悪意のあるbridgeParamsとともに呼び出します。bridgeParams.targetをCheckoutPaymasterに設定し、bridgeParams.callDataをactivateAndCall()への呼び出しとしてエンコードし、外部UserOperationを内部ペイロードとして渡します。

- ステップ4:新しいCheckoutPool(0x1929...0215)の
execute()に到達し、85,730USDCを外部UserOperationのops[0].senderとして指定されたアドレス0xb648に転送します。

- ステップ5:
EntryPoint.handleOps()に入ります。0xb648が送信者とペイマスターの両方として機能するため、アカウント検証とペイマスター検証の両方が攻撃者の制御下にあり、攻撃者は85,730USDCの利益を得ることができました。
結論
このインシデントは、レガシーCheckoutPoolがbridge()パスにアクセス制御とキャルデータから受信者へのバインディングの両方を欠いていたことによって引き起こされ、約85.7Kドルの損失が発生しました。同様のインシデントを防ぐために、プロトコルは機密性の高いルーティングおよび決済フロー全体で厳格なアクセス制御を強制し、外部から提供されたペイロードがプロトコルから派生した受信者と一致していることを確認し、パッチが適用された代替品がデプロイされたら、信頼された特権関係から古くなったコントラクトを削除する必要があります。
4. Keom Incident
概要
2026年3月18日、Polygon zkEVM上のCompound V2フォークレンディングプロトコルであるKeomが、約35Kドルで不正利用されました。根本原因は、redeemUnderlying()によって呼び出されるredeemFresh()における会計ロジックの不備でした。この関数は、シェアの削減をユーザーの実際の残高に上限設定しましたが、それに対応する裏付け資産の引き出し額を再計算しませんでした。この不一致により、攻撃者はシェアが許可するよりもはるかに多くの資産を引き出すことができました。
背景
KeomはCompound V2からフォークされたレンディングプロトコルです。ユーザーは市場にETHを供給し、kETHを受け取ります。ユーザーが引き出しを行うと、プロトコルは現在の交換レートを使用して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.6ETH)を引き出します。不備のある会計を悪用して、市場からETHを drainします。

結論
このインシデントは、redeemTokensをユーザーの実際の残高に上限設定した後redeemAmountを再計算しない会計上の脆弱性によって引き起こされ、約35Kドルの損失が発生しました。償還ロジックは、任意の上限または調整の後、シェアから裏付け資産への不変性を維持するために、すべての依存値を再計算する必要があります。Compound V2フォークは、他の誘導体にも同様の欠陥が存在する可能性があるため、このパスを注意深くレビューする必要があります。
5. ShiMama Incident
概要
2026年3月18日、BNB Chain上のデフレトークンプロトコルであるShiMamaが、約35Kドルで不正利用されました。根本原因は、executePairBurn()関数に対するアクセス制御の欠如であり、これにより任意のユーザーがペアリザーブの引き出しとバーンをトリガーでき、価格操作が可能になりました。
背景
ShiMama Protocolは、AMMペアからトークンをプルしてバーンすることを目的としたオンチェーンのデフレメカニズムを含んでいます。このメカニズムは、ShiMama ProtocolとShiMama Token全体に実装されています。ShiMama ProtocolのexecutePairBurn()関数は、呼び出し元が提供するreferenceInパラメータに基づいてプル額を計算します。
pullAmt = referenceIn * pairBurnBpOnSell / 10_000
次に、ShiMama TokenのforcePullFromPair()、続いてpair.sync()を呼び出し、プルされたトークンをバーンします。
脆弱性分析
根本原因は、ShiMamaProtocolコントラクト(0x5049...0b49a)のexecutePairBurn()に対するアクセス制御の欠如です。この関数は制限なく外部から呼び出し可能であるため、任意のユーザーが特権リザーブ移動とペア同期をトリガーできます。referenceInも呼び出し元によって制御され、実際の売り額にバインドされていません。ShiMamaToken.forcePullFromPair()では、プロトコルは制約なしにPancakeペアから直接残高を移動でき、任意の残高抽出と即時の同期、したがってスポット価格操作を可能にします。

攻撃分析
以下の分析は、攻撃トランザクション 0x13959b...3c20e001に基づいています。
-
ステップ1:Moolah flashLoanから
WBNBを借入ます。 -
ステップ2:以前のトランザクションで調達された30.78e18
ShiMamaを攻撃コントラクトに転送します。直接のShiMamaのPancakeペアからの購入が無効になっていたため、攻撃者は攻撃前にShiMama Protocolで流動性を提供および引き出しすることでShiMamaを調達しました。 -
ステップ3:
executePairBurn()を呼び出し、Pancakeペアから1,311,349,143.96ShiMamaトークンをプルしてバーンし、ShiMama価格を効果的にインフレさせます。 -
ステップ4:攻撃者は、インフレした価格でPancakeSwapで30.78e18
ShiMamaを52.98e18WBNBと交換しました。 -
ステップ5:フラッシュローンを返済し、52.98
WBNBを純利益として残しました。

結論
このインシデントは、executePairBurn()へのアクセス制御の欠如によって引き起こされ、プールリザーブを変更する不正なパスを公開しました。リザーブを変更する機能は経済的に敏感であり、厳格に許可される必要があります。呼び出し元が制御する入力は、リザーブ抽出の増幅を防ぐために、プロトコルから派生した値にバインドされる必要があります。
6. BlindBox Incident
概要
2026年3月19日、BNB Chain上のGameFiベッティングプロトコルであるBlindBoxが、約99Kドルで不正利用されました。根本原因は、弱い乱数性であり、攻撃者が結果を予測し、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がゼロを返し、フォールバックパスがアクティブになるようにします。攻撃者はその後、オフチェーンで結果をシミュレートし、計算された結果が有利なブロックでのみsettle()を呼び出しました(例:0x68eedc...718ce8)。

結論
このインシデントは、予測可能な乱数性とTWAP入力としての操作可能なスポット価格の組み合わせによって引き起こされ、約99Kドルの損失が発生しました。同様のリスクを軽減するために、プロトコルはblockhashウィンドウが期限切れになった後に予測可能になる決済パスを削除し、getTwapPrice()を短期的なリザーブ操作に耐性のある価格ソースに置き換える必要があります。
7. Resolv Incident
概要
2026年3月22日、Ethereum上のステーブルコインプロトコルであるResolvは、インフラストラクチャキーの侵害により、特権的なスワップ完了ロジックの不正実行を可能にしました。このインシデントでは、攻撃者は特権関数を悪用して8000万ドル以上の担保なしUSRをミントしました。影響は直接のミントイベントを超えて広がり、結果として生じたUSRのデペッグは、Resolv資産が担保として使用されていた、より広範な連鎖反応を引き起こしました。
背景
Resolvは、USRの発行が担保付きスワップ決済に依存するステーブルコインプロトコルです。そのスワップ完了パイプライン、completeSwap() -> mint() -> transfer()は、USRの流通供給量に直接影響するため、認可の整合性と担保の整合性の両方に依存します。通常の運用では、Resolvコントラクト(0xa27a...5861)のcompleteSwap()は、対応する担保預け入れが検証された後、特権インフラストラクチャキー(コードではSERVICE_ROLEと呼ばれる)のみが呼び出すことができました。

脆弱性分析
インシデントは、特権キーの侵害によって引き起こされ、同等の担保流入なしに信頼された決済ロジックを呼び出してUSRミントパスに到達させました。攻撃者が特権署名権限を制御した後、completeSwap()パスはオンチェーンのミント前提条件の強制を全く提供しませんでした。担保検証は完全にオフチェーンの認可に依存していました。これにより、コントロールプレーンの侵害が供給整合性の障害に直接変換されました。
攻撃分析
-
ステップ1:エクスプロイトに先立ち、攻撃者はトランザクション0x590b5c...de732c89でスワップリクエストを送信し、後続の悪意のあるスワップ完了のための必要な状態を準備しました。
-
ステップ2:侵害された特権キーを使用して、攻撃者は
completeSwap()を呼び出して、3つのトランザクション(0xfe37f2...dc33743、0x41b6b9...db1f18f、および0x7f9143...53a931d)で8000万ドル以上のUSRをミントしました。
結論
このインシデントは、信頼されたオペレーターロールだけでなく、ハードなオンチェーンミント前提条件にステーブルコインの安全性が依存していることを浮き彫りにしました。注目すべきは、このインシデントの影響は、不正なUSRミントの8000万ドルをはるかに超えました。Resolv資産は複数のレンディングプロトコル全体で広く担保として使用されていたため、デペッグはより広範な連鎖反応を引き起こしました。Chaos Labsによって報告されたように、自動化された利回り追求型配分を使用するオンチェーンキュレーターは、リアルタイムのリスク管理を欠いており、既に損なわれた市場に新鮮な資本を directedし続けました。局所的なエクスプロイトとして始まったものは、すぐにクロスプロトコル連鎖反応イベントにエスカレートし、レンディングプロトコルに数百万ドルの不良債務を残しました。
BlockSecについて
BlockSecは、フルスタックのブロックチェーンセキュリティおよびクリプトコンプライアンスプロバイダーです。私たちは、顧客がコード監査(スマートコントラクト、ブロックチェーン、ウォレットを含む)、リアルタイムでの攻撃傍受、インシデント分析、不正資金の追跡、およびAML/CFT義務の遵守を、プロトコルとプラットフォームのライフサイクル全体にわたって実行するのに役立つ製品とサービスを構築しています。
BlockSecは、権威あるカンファレンスで複数のブロックチェーンセキュリティ論文を発表し、いくつかのゼロデイ攻撃を報告し、2,000万ドル以上を救済するために複数のハッキングをブロックし、数十億ドルの暗号通貨を保護しました。
-
公式ウェブサイト: https://blocksec.com/
-
公式Twitterアカウント: https://twitter.com/BlockSecTeam



