流動性の低いトークンの価格を吊り上げて高価値資産を借り入れるこの手法は、従来の「フラッシュローン攻撃」と同じものなのか？
両者には重なりがあるが、完全に同一というわけではない。フラッシュローン攻撃の核心は、大金を借り、同一取引内で価格を操作し、借入を返済するというものだ。一連の流れは単一のブロック内で完結し、攻撃者は自分自身の相当な資本を用意する必要がない。今回のMoonwell事件の攻撃者は、3時間以上にわたって段階的にMAMOを買い進めて価格を押し上げており、これは単一取引内で完結するフラッシュローンパターンではなく、現物市場操作にあたる。
両者に共通するのは、どちらも「プロトコルが信頼する価格」と「実際の市場価格」との差を利用して価値を引き出すという点だ。違うのは操作の手法と時間の長さである。だからこそこの記事は、これをオラクル操作というより広い分類の下に位置づけている——フラッシュローンは価格操作を達成するための一つの手段にすぎず、唯一の経路ではない。標的となるトークンが十分に非流動的であれば、フラッシュローンに頼らずとも、持続的な買い圧力だけで同様の効果を達成できるのだ。
Moonwellは過去10か月間ですでに価格に関連する3件の損失事件を経験しているが、なぜプロトコル側はもっと早くこの弱点に対処しなかったのか？
この問いに対する明確な公式の説明は今のところないが、3件の事件の性質から構造的な難しさが見えてくる。最初の2件（wrsETHとcbETH）は、オラクルそのものの計算誤りや設定ミスであり、性質としてはエンジニアリング実装上の欠陥に近く、通常はその特定のデータソースを修正することで対処される。今回のMAMO事件は異なる——オラクルそのものの動作ロジックは間違っていなかった。オラクルは公開市場でのMAMOの実際の取引価格を忠実に報告していたのだ。問題はさらに上流、そもそもこれほど流動性の薄いトークンを担保として貸付市場に受け入れるという、より早い段階のプロダクト判断にあった。
言い換えれば、最初の2件が修正したのは「オラクルが価格を読み間違えた」ことであり、今回直面しているのは「オラクルは価格を正しく読んだが、その価格自体が容易に操作されうる」ということだ。これはまったく異なる階層の問題であり、プロトコルは単一のデータソースの技術的誤りを修正するだけでなく、どの担保を上場させるかというリスク評価基準全体を見直す必要がある。だからこそ、2度の教訓があったにもかかわらず、今回は事前に防ぐことができなかったのだ。
貸付プロトコルが流動性の低いトークンを担保として一切受け入れなければ、この種の攻撃を完全に回避できるのか？
そうすればリスクは大幅に減るが、完全な回避にはならない。なぜなら「十分な流動性があるかどうか」は時間とともに変化する状態であり、一度きりの判断で永久に成立する条件ではないからだ。あるトークンは、プロトコルがそれをホワイトリストに登録し担保として許可した時点では、実際に十分な取引の厚みを持っていたかもしれない。しかし市場の熱が冷め、取引量が縮小すれば、同じトークンが数か月後には流動性の薄い状態になりうる。すでに上場している担保に対して継続的な流動性監視と動的な調整を行わなければ、今日安全な担保が、将来のある時点で攻撃者の次の標的になりかねない。
より実践的な防御策は、単一市場のリアルタイム価格だけに頼るのではなく複数の価格ソースを組み合わせること、価格変動の速度に連動した借入上限とサーキットブレーカーを設定すること、そして流動性が弱まっている既存の担保に対しては動的に借入可能額を引き下げることだ——一度きりの上場審査を永続的な解決策として扱うのではなく。だからこそ記事は、セキュリティ企業が「担保リスクスコアリング」のようなメカニズムを推進していると述べている——この種の継続的な監視を標準化し、各プロトコルが独自に手探りするのではなくすることが狙いだ。
自分の資産が現在Moonwell以外のDeFi貸付プロトコルに預けられている場合、そのプロトコルにも同様のリスクがあるかどうか、自分である程度事前に判断する方法はあるか？
比較的取り組みやすいチェック方法がある。使っているプロトコルが公開している「受け入れ可能な担保リスト」を見つけ、そのリストにある各トークンの現在の市場取引量と流動性の厚みを一つずつ確認する（ほとんどのトークンの24時間取引量は、ブロックチェーンエクスプローラーや主要な相場情報サイトで直接確認できる）。リストの中に日次取引量が明らかに低いトークンがあったり、主要な取引ペアが1つか2つの規模の小さい取引所に集中していたりする場合、それはそのトークンの価格が比較的容易に人為的に動かされうることを意味する。このような担保がプロトコルに存在すること自体が、注意すべきリスクシグナルとなる。
さらに確認できるのは、そのプロトコルのオラクルメカニズムが単一市場のリアルタイム価格のみに依存しているのか、それとも複数のソースを組み合わせているか、あるいは時間加重平均のような操作耐性のある設計を取り入れているかどうかだ——ほとんどの成熟したプロトコルは、文書やガバナンスフォーラムでオラクルの技術的詳細を公開している。自分の資産を預けているプロトコルが「流動性の低いトークンが担保として存在する」ことと「オラクルの防御メカニズムが明確でない」ことの両方に該当する場合、それはさらに注目し、場合によっては曝露を減らすことを検討すべき具体的なシグナルであり、プロトコルが実際に被害に遭ってから後になって気づく必要はない。
2026年8月27日、Coinbase傘下のレイヤー2ネットワークBase上で運営されている貸付プロトコルMoonwellは、わずか3時間強のうちに約870万ドルを失った——そしてこの事件全体を通じて、攻撃者は脆弱なコントラクトコードを1行も見つけておらず、どのスマートコントラクトのアクセス制御もバイパスしていない。この事件がオラクル操作と併せて学ぶ価値があるのは、まさに一つのことを正確に示しているからだ——貸付プロトコルにとって、「コントラクトコード自体にバグがない」ことと「このプロトコルが安全である」ことは、まったく別の主張だということだ。
プロトコルの事後報告およびPeckShield、CertiK、Blockaidといったセキュリティ企業の追跡によれば、攻撃は8月27日協定世界時06:09から09:30の間に展開された。攻撃者が標的にしたのはMAMO——極めて流動性が低く薄い取引量しかないトークンで、中規模の売買注文でさえ価格を大きく動かすことができる。継続的な買い注文を通じて、攻撃者はMAMOの価格を約0.0106ドルから最高約0.4313ドルへと押し上げた。これはおよそ40倍の上昇だ。Moonwellのシステムが実際に有効と認めた最高価格は約0.4025ドルだった。攻撃者はその後、水増しされたMAMO保有分をMoonwellに担保として預け入れた——システムが認識する価格が人為的に吊り上げられたものだったため、そのMAMOは実際の市場価値をはるかに超える借入能力を示し、攻撃者はcbBTC（コインベースラップドビットコイン）、WETH、USDC、wstETHを合わせて約1,103万ドル相当借り入れることができた。価格が崩壊した後、これらの借入は清算メカニズムを通じて回収することができなかった。
オラクルとは、プロトコルがトークンのリアルタイム価格を取得するための仕組みである——オラクルがなければ、オンチェーンのコントラクトは担保が現在いくらの価値を持つか知る方法がなく、したがって借入額が妥当かどうかを計算する方法もない。今回の攻撃がまさにそこに梃子を入れたのだ——オラクルに歪んだ価格を報告させることさえできれば、コントラクト自体にはコードの脆弱性はまったく必要ない。なぜなら、コントラクトは単に、自分が「信頼している」価格の数字に基づいて忠実に計算を実行しているだけであり、その数字が最初から間違っていたからだ。これこそが、複数の報道が「コードの脆弱性は見つからなかった」ことを特に強調している理由である——プロトコルがそれによって安全だったということではなく、リスクの発生源がそもそもコード監査が通常注目する場所にはなかったことを示しているのだ。
追跡報告によれば、過去10か月間だけで、価格関連の問題がMoonwellに1,400万ドル以上の損失をもたらしている——2025年11月のwrsETHオラクルの不具合は約370万ドルの不良債権を生み、2026年2月のcbETH価格設定の誤り（約2,200ドルの価値がある資産を約1.12ドルと誤って評価）はさらに約178万ドルの不良債権を追加した。今回のMAMO事件は累積損失をさらに押し上げ、あるパターンを明確にしている——このプロトコルに繰り返し代償を払わせているのは、コード自体が破られたことではなく、価格データそのものが誤っていることであり、3件の事件すべてが同じ根本的な問題のカテゴリに行き着く。
事件を受けて、Moonwellはbase上のすべてのCore Marketの借入上限を1 wei——イーサリアムの会計システムにおける最小単位——に引き下げた。これは事実上、既存の預金の引き出しには影響を与えずに新規借入を完全にブロックするものだ。MAMOとMoonwell自身のガバナンストークンWELLの供給上限も同様に1 weiに引き下げられた。この対応は損失のさらなる拡大を食い止めたが、すでに発生した不良債権は解決していない——プロトコルが翌日に公表した数字によれば、MAMO市場には約913万ドルの未回収借入ポジションが残っており、対応する支払能力のある借り手が見つからない状態だ。この不足分を最終的に誰が負担するのかは、まだ結論が出ていない。
あなたの資産がDeFi貸付プロトコルに預けられている場合、この事件は、現在利用しているプロトコルに直接適用できる具体的な問いを投げかけている——その貸付市場はどのトークンを担保として受け入れているか、そしてそれらのトークンの価格データはどこから来ているか。ある市場が流動性の低い、薄く取引されるトークンを担保として許可している場合、コントラクトコード自体がどれほど厳密に監査されていても、攻撃者は常にそのトークンの市場価格を操作し、コントラクトに誤った担保価値を「信じ」させる経路を持っている。これはコントラクトにバグがあるかどうかとは関係がなく、より根本的な問題だ——ある貸付市場のリスクは、プロトコルが設計された瞬間から、どの価格ソースを信頼するかによってすでに決まっているのである。