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

過去1週間（2026年3月16日～2026年3月22日）、BlockSecは7件の攻撃インシデントを検出し分析しました。総損失額は約8,270万ドルと推定されています。以下の表にこれらのインシデントをまとめ、各ケースの詳細な分析は以降のセクションで提供します。

1. Venus Incident

概要

2026年3月15日、BNB Chain上のVenus ProtocolのTHE（Thena）市場は、ドネーション攻撃と市場操作を組み合わされた攻撃を受け、約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つの相乗的なベクトルが関与しました。

ドネーション攻撃

プロトコルは、市場コントラクトの生のトークン残高から直接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,447ETHを受け取りました。その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までに、攻撃者のポジションは供給上限の約3.67倍に相当する約5,320万THEに達し、総借入エクスポージャーは約1,490万ドルでした。

• ステップ6：その後、ポジションは大規模な清算に入りました。254の清算人アドレスからの8,048件の清算トランザクションを通じて、約4,200万THEの担保が清算されました。売却が続いたため、THEトークンは0.22ドルまで下落しました。清算 proceeds は全負債をカバーできず、Venusは約215万ドルの純不良債権を抱えることになりました。

結論

このインシデントでは、新しい脆弱性は明らかになりませんでした。それは、各レイヤーが他のレイヤーが機能すると仮定した場合、よく知られた攻撃ベクトルが、体系的に実行されることでプロトコルのリスクスタック全体を圧倒できることを示しました。オンチェーンでは数ヶ月前から警告信号が見られましたが、検出と介入の間のギャップは未解決のままでした。流動性認識リスクパラメータ、自動サーキットブレーカー、およびポジションレベルの監視を通じてそのギャップを埋めることが、このインシデントが他のレンディングプロトコルに残す中心的な教訓です。

詳細な分析については、私たちのディープダイブ投稿[1]を参照してください。

参考文献

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

2. dTRINITY Incident

概要

2026年3月17日、Ethereum上のAave V3フォークレンディングプロトコルであるdTRINITYは、dLENDレンディング市場を通じて悪用され、約257,300ドルの損失が発生しました。根本原因は、Aave V3フォークに固有の空市場の脆弱性でした。リザーブがほぼゼロの流動性を保持している場合、フラッシュローンプレミアムの繰り返し蓄積がliquidityIndexを極端な値に駆動します。リザーブ会計が歪められた後、攻撃者は預け入れと引き出しパスの精密損失を悪用して担保を過大評価し、dUSDを借り入れ、預け入れたcbBTCを回収して純利益を得ました。

背景

dTRINITYは、dUSDステーブルコインシステムと、Aave V3からフォークされたレンディング市場であるdLENDを含んでいます。コアL2Poolコントラクト（0xfda3...e19e84）では、各資産は独自の準備金を持ち、準備金会計はスケーリングされた残高と準備金レベルliquidityIndexに基づいています。ユーザーの現在の裏付け残高は、スケーリングされた残高に準備金の正規化された収入を掛けたものから導出されます。

フラッシュローンプレミアムは、cumulateToLiquidityIndex()を通じて準備金会計に追加されます。ここで：

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

totalLiquidityが極端に小さくなると、各プレミアムの蓄積がliquidityIndexを異常に速い速度で上昇させることができます。

脆弱性分析

攻撃の鍵となる条件は、dLEND-cbBTC市場（0x504d...3acc）におけるほぼ空のリザーブでした。リザーブが単一スケーリングシェアに圧縮されると、フラッシュローンプレミアムはもはや意味のある供給ベースに分散されなくなりました。したがって、繰り返し行われたフラッシュローンは、liquidityIndexを非常に急速に上昇させる原因となりました。

liquidityIndexがインフレした後、裏付け資産からスケーリングされた変換は極端な丸め処理の領域に入りました。この状態では、少量の預け入れが1つの追加シェアをミントする可能性がありますが、はるかに大きな引き出しでも1つのシェアしかバーンしない可能性があります。この非対称性により、攻撃者は過大評価されたaCbBTC担保を構築し、別のリザーブから実際のdUSDを借りることができました。なぜなら、ヘルスチェックはPoolレベルで実行され、破損したcbBTCリザーブがクロスアセット借入能力に直接影響を与えるためです。

攻撃分析

このエクスプロイトは、2つのトランザクションで構成されていました：0x8d33d6...40ae7139 および 0bec4c8...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,999,979,728,276まで上昇させます。

• ステップ6：繰り返しの預け入れと引き出しサイクルを実行して、残りのリザーブキャッシュを抽出します。

• ステップ7：フラッシュローンを返済します。

トランザクション2：利益実現

• ステップ1：再びMorpho BlueからcbBTCを借入ます。

• ステップ2：すでに操作されたリザーブに約7.72cbBTCを預け入れ、過大評価されたaCbBTC担保ポジションを構築します。

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

• ステップ4：繰り返しの預け入れ/引き出しサイクルを通じてcbBTCの抽出を続けます。

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

結論

このインシデントは、Aave V3フォーク全体で広く文書化されている空市場攻撃の事例です。このパターンは複数のプロトコルで出現しており、緩和策は確立されています。リザーブ初期化中に最小供給閾値を強制することで、リザーブがインデックス成長の制御不能になる状態に入るのを防ぎます。したがって、Aave V3をフォークするプロトコルは、リザーブのブートストラップを重要な操作として扱い、インデックスを安定させるための有機的な預け入れフローに依存するのではなく、デプロイ時に実質的な流動性をロックすることを保証する必要があります。

3. Fun.xyz Incident

概要

2026年3月17日、Polygon上のチェックアウトインフラストラクチャプロトコルであるFun.xyzが約85,700ドルで悪用されました。根本原因は、レガシー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で悪意のあるbridgeParamsを使用してbridge()を呼び出します。bridgeParams.targetをCheckoutPaymasterに設定し、bridgeParams.callDataをactivateAndCall()の呼び出しとしてエンコードし、外部UserOperationを内部ペイロードとして渡します。

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

• ステップ5：EntryPoint.handleOps()に入ります。0xb648が送信者とペイマスターの両方として機能するため、アカウント検証とペイマスター検証の両方が攻撃者の制御下にとどまり、攻撃者は85,730 USDCの利益を得ることができました。

結論

このインシデントは、レガシーCheckoutPoolがbridge()パスにアクセス制御とコールデータから受信者へのバインディングの両方を欠いていたことに起因し、約85,700ドルの損失が発生しました。同様のインシデントを防ぐために、プロトコルは機密のルーティングおよび決済フロー全体に厳格なアクセス制御を強制し、外部から提供されるペイロードがプロトコルから導出された受信者と一致することを確認し、パッチが適用された代替物がデプロイされたら、信頼された権限関係から古くなったコントラクトを削除する必要があります。

4. Keom Incident

概要

2026年3月18日、Polygon zkEVM上のCompound V2フォークレンディングプロトコルであるKeomが、約35,000ドルで悪用されました。根本原因は、redeemUnderlying()から呼び出されるredeemFresh()における誤った会計ロジックでした。この関数は、シェアの減少をユーザーの実際の残高に上限設定しましたが、裏付け資産の引き出し額はそれに応じて再計算されませんでした。この不一致により、攻撃者はシェアで許可されるよりもはるかに多くの資産を引き出すことができました。

背景

KeomはCompound V2からフォークされたレンディングプロトコルです。ユーザーは市場にETHを供給し、kETHを受け取ります。ユーザーが償還する場合、プロトコルは現在の交換レートを使用してkETHシェアをETHに変換します。プロトコルには2つの償還エントリポイントがあります：シェア額による償還のためのredeem()と、希望する裏付け資産額による償還のためのredeemUnderlying()です。

脆弱性分析

欠陥は、kETH市場（www.oklink.com/polygon-zkevm/address/0x4c6e83b9f7e8835f583be748de899c5881fbc403/contract）のredeemFresh()にあり、これはredeemUnderlying()から呼び出されます。ユーザー制御の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.001ETHでmint()を呼び出し、最小限のkETH残高を取得します。

• ステップ2：exitMarket()を呼び出してkETH市場におけるアカウントのメンバーシップをクリアし、redeemAllowed()が流動性チェックを完全にバイパスするようにします（脆弱性分析で説明したとおり）。

• ステップ3：redeemUnderlying()を呼び出して、市場の全ETH残高（約38.6ETH）を引き出します。誤った会計を悪用して市場からETHをドレインします。

結論

このインシデントは、redeemTokensをユーザーの実際の残高に上限設定した後redeemAmountを再計算しない会計脆弱性によって発生し、約35,000ドルの損失が発生しました。償還ロジックは、キャップまたは調整後にすべての依存値を再計算して、シェアから裏付け資産への不変性を維持する必要があります。Compound V2フォークは、他の誘導体にも同様の欠陥が存在する可能性があるため、このパスを慎重にレビューする必要があります。

5. ShiMama Incident

概要

2026年3月18日、BNB Chain上のデフレショントークンプロトコルであるShiMamaが、約35,000ドルで悪用されました。根本原因は、executePairBurn()関数に対するアクセス制御の欠如であり、これにより任意のユーザーがペアリザーブの引き出しとバーンをトリガーでき、価格操作が可能になりました。

背景

ShiMama Protocolは、AMMペアからトークンを引き出してバーンすることを目的としたオンチェーンのデフレメカニズムを含んでいます。このメカニズムは、ShiMama ProtocolとShiMama Token全体で実装されています。ShiMama ProtocolのexecutePairBurn()関数は、呼び出し元が提供するreferenceInパラメータからプル量：

pullAmt = referenceIn * pairBurnBpOnSell / 10_000

を計算します。その後、ShiMama TokenのforcePullFromPair()、続いてpair.sync()、そしてプルされたトークンのバーンを呼び出します。

脆弱性分析

根本原因は、ShiMamaProtocolコントラクト（https://bscscan.com/address/0x5049d10378356fde0b44c93fa7bb75836f10b49a）におけるexecutePairBurn()のアクセス制御の欠如です。この関数は制限なく外部から呼び出し可能であり、任意のユーザーが特権リザーブ移動とペア同期をトリガーできます。referenceInも呼び出し元が制御可能であり、実際の売り上げ額にはバインドされていません。ShiMamaToken.forcePullFromPair()では、プロトコルは制約なしにPancakeペアから直接残高を移動できるため、任意の準備金除去と即時同期を可能にし、したがってスポット価格操作を可能にします。

攻撃分析

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

• ステップ1：Moolah flashLoanからWBNBを借入ます。

• ステップ2：以前のトランザクションで調達された30.78e18ShiMamaを攻撃コントラクトに転送します。Pancakeペアからの直接のShiMama購入が無効になっていたため、攻撃者は攻撃前にShiMama Protocolで流動性を提供および引き出しすることでShiMamaを調達しました。

• ステップ3：executePairBurn()を呼び出し、Pancakeペアから1,311,349,143.96ShiMamaトークンをプルしてバーンし、実質的にShiMama価格をインフレさせます。

• ステップ4：攻撃者は、インフレした価格でPancakeSwapで30.78e18ShiMamaを52.98e18WBNBと交換しました。

• ステップ5：フラッシュローンを返済し、純利益として52.98WBNBを残します。

結論

このインシデントは、executePairBurn()へのアクセス制御の欠如に起因し、不正な準備金変更経路を公開しました。準備金を変更する機能は経済的に機密であり、厳格に許可されている必要があります。呼び出し元制御の入力は、準備金抽出の増幅を防ぐために、プロトコルから導出された値にバインドされる必要があります。

6. BlindBox Incident

概要

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

背景

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

脆弱性分析

BlindBoxコントラクト（https://bscscan.com/address/0x1F8336aEF584795E282FECe8DE356BaBD7734c59）には2つの脆弱性が含まれています：

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

2. 操作可能な価格制限: プロトコルはベットサイズを制限するためにgetTwapPrice()を使用します。しかし、この関数は真の時間加重平均価格を実装しておらず、代わりにATM/USDTプール内のスポット価格を読み取ります。これにより、攻撃者はベットを配置する前にプール価格を操作して制限を回避できます。

攻撃分析

以下のステップは、攻撃パターンを示しています。ステップ2と3はペアになったシーケンスを形成しました（例：betId=5,284）。攻撃者はこのペアを複数回繰り返して利益を蓄積しました。

• ステップ1：ATM/USDTプールを操作し、ATMスポット価格をインフレさせて、次のステップでgetTwapPrice()がより大きなベットサイズを許可するようにしました。

• ステップ2：インフレした許容ATM額をデッドアドレス（例：0x4be049...3af12c）に転送して、大きなベットを配置しました。

• ステップ3：256ブロック以上経過するのを待ち、blockhashがゼロを返し、フォールバックパスがアクティブになるようにしました。攻撃者はその後、オフチェーンで結果をシミュレーションし、計算された結果が有利なブロックでのみsettle()を呼び出しました（例：0x68eedc...718ce8）。

結論

このインシデントは、予測可能な乱数と、TWAP入力としての操作可能なスポット価格が組み合わされたことによって発生し、約99,000ドルの損失が発生しました。同様のリスクを軽減するために、プロトコルはblockhashウィンドウの有効期限が切れた後に予測可能になる決済パスを削除し、getTwapPrice()を短期的なリザーブ操作に耐性のある価格ソースに置き換えるべきです。

7. Resolv Incident

概要

2026年3月22日、Ethereum上のステーブルコインプロトコルであるResolvは、インフラストラクチャキーの侵害により、特権的なスワップ最終化ロジックの不正実行を可能にしました。このインシデントでは、攻撃者は特権関数を悪用して8,000万以上の裏付けのないUSRをミントしました。影響は直接のミントイベントを超え、結果として生じたUSRのペッグずれが、Resolv資産が担保として使用されていた広範なレンディングプロトコル全体に波及しました。

背景

Resolvはステーブルコインプロトコルであり、USRの発行は担保裏付けスワップ決済に依存しています。そのスワップ完了パイプライン、completeSwap() -> mint() -> transfer()は、USRの流通供給量に直接影響を与え、したがって承認の完全性と担保の完全性の両方に依存します。通常の運用では、Resolvコントラクト（https://etherscan.io/address/0xa27a69ae180e202fde5d38189a3f24fe24e55861）のcompleteSwap()は、対応する担保預け入れが検証された後にのみ、特権インフラストラクチャキー（コードではSERVER_ROLEと呼ばれる）によって呼び出し可能でした。

脆弱性分析

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

攻撃分析

• ステップ1：エクスプロイトに先立ち、攻撃者はトランザクション 0x590b5c...de732c89 でスワップリクエストを送信し、その後の悪意のあるスワップ完了のための必要な状態を準備しました。

• ステップ2：侵害された特権キーを使用して、攻撃者は3つのトランザクション（0xfe37f2...dc33743、0x41b6b9...db1f18f、および0x7f9143...53a931d）でcompleteSwap()を呼び出し、8,000万以上のUSRをミントしました。

結論

このインシデントは、信頼されたオペレーターロールだけでなく、ハードなオンチェーンミント前条件がステーブルコインの安全性に依存していることを強調しています。特に、このインシデントの影響は、不正にミントされた8,000万ドルのUSRをはるかに超えました。Resolv資産は複数のレンディングプロトコル全体で広く担保として使用されていたため、ペッグずれはより広範な伝染を引き起こしました。Chaos Labsによって報告されたように、自動利回り追求型配分を使用するオンチェーンキュレーターは、リアルタイムのリスク管理を欠き、すでに損なわれた市場への新鮮な資本の指示を続けました。局所的なエクスプロイトから始まったものは、すぐにクロスプロトコル伝染イベントにエスカレートし、レンディングプロトコルに数百万ドルの不良債権を残しました。

BlockSecについて

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

BlockSecは、名誉あるカンファレンスで複数のブロックチェーンセキュリティ論文を発表し、DeFiアプリケーションのゼロデイ攻撃を複数報告し、ハッキングをブロックして2,000万ドル以上を救済し、数十億ドルの暗号通貨を確保してきました。

• 公式ウェブサイト: https://blocksec.com/

• 公式Twitterアカウント: https://twitter.com/BlockSecTeam

• 🔗 BlockSec監査サービス : リクエストを送信

• 🔗 Phalcon Security APP: デモを予約

• 🔗 Phalconコンプライアンス