約160万ドルの損失：MokeトークンとLpdFiへの攻撃

先週（2026/08/03 - 2026/08/09）、注目すべきセキュリティインシデントが2件発生し、合計約160万ドルの損失が生じました。

日付	インシデント	種類	推定損失
2026/08/03	LpdFi	価格操作	~$697K
2026/08/03	Moke Token	価格操作・会計エラー	~$906K

LpdFi が選ばれた理由は、操作可能なAMMリザーブをポジション評価と利息償還の両方に使用することで生じるシステミックリスクを示しているからです。攻撃者はまずスポット価格の操作によって記録された元本を水増しし、次に直接の寄付と sync() を通じてプールのリザーブを変更することで、過大な利息請求を実行可能な状態にしました。これは、預け入れ評価・利息計算・償還を独立した操作として扱うのではなく、ポジションのライフサイクル全体を通じてソルベンシーを検証することの重要性を示しています。
Moke Token が選ばれた理由は、独立した会計メカニズムに存在する脆弱性を組み合わせて単一の収益性ある攻撃を実現する方法を示しているからです。攻撃者はスポット価格を操作してクレーム可能な MOKE の量を水増しし、同一のLPトークンを複数のアドレスに同期させることでLPリワードの記録を重複させ、得られたトークンを配当システムを通じて引き出し可能な BNB に変換しました。これは、操作耐性のある価格ソースを使用することと、リワードの会計を実際のトークン保有と同期させ続けることの重要性を示しています。

今週のハイライト：LpdFiプロトコル

このインシデントがハイライトされた理由は、同一の操作可能なAMMステートが負債の生成と資産の償還の両方を支配していたからです。プロトコルが預け入れ評価・利息発生・償還を独立したステップとして扱うのではなく、ポジションのライフサイクル全体を通じてソルベンシーを検証しなければならない理由を示しています。

2026年8月3日、BNBチェーン上の LpdFi プロトコルが約$697Kの被害を受け、LPD/USDC PancakeSwapペアから資金が流出しました。LpdFi はポジションの記録価値とその後の利息支払いの両方を同じライブPancakeSwapペアから導出していたため、そのペアを操作することで両方が歪められました。攻撃者は実際の価値をはるかに上回る評価でポジションを開き、利息が発生するのを待った後、プールのリザーブをシフトさせて過大な利息請求が支払われるようにし、プロトコルが保有していたほぼすべての流動性を流出させました。

背景

LpdFi は LPD トークンを中心に構築されたイールドプロトコルです。ユーザーは LPD を預けることでポジションを作成します。預け入れ時、プロトコルは現在のLPD/USDC PancakeSwapスポット価格を使用して預け入れを評価し、その結果をオーダーのUSD建て元本である uAmount として保存します。オーダーはイシューによって利息が発生し、各イシューは1日の会計期間であり、プロトコルは各オーダーの総利息を記録された元本に対して上限を設けています。

ユーザーが利息を請求すると、プロトコルは LpdFi が保有するLPトークンを使用してLPD/USDCペアから流動性を取り除くことで、会計上の利息を USDC に変換します。償還された USDC は請求者と手数料アドレスに分配されます。ポジションのライフサイクルの両端、すなわち預け入れ時の評価と償還時の支払いは、同じライブPancakeSwapペアから読み取られます。

脆弱性の分析

バグのあるコントラクトは 0xce6a...f295e と 0x3876...273604 です。

根本原因は、LpdFi がオーダー会計と利息償還の両方の真実のソースとして、ライブのLPD/USDCスポット価格とリザーブを使用していたことです。どちらの値も信頼するには不安全です：どちらも、十分な一時的流動性を持つ呼び出し元が単一のトランザクション内で移動させることができるペアリザーブから導出されています。

預け入れ時、buy() は token.price() からトークン量を計算します：

LPD.price() は getReserves() を通じてLPD/USDCリザーブを直接読み取るため、記録された元本はスポット価格とともに変動します：

償還時、claimInterest() は removeLp() を呼び出して発生した利息を支払います：

removeLp() はライブリザーブ r1（または r0）からバーンするLPトークンの数を計算します：

その結果、2つの不変条件が破られます。第一に、記録された元本がスポット価格から導出されるため、預け入れの実際の価値をはるかに超える元本が記録される可能性があり、利息の上限が引き上げられます。第二に、removeLp() がライブリザーブからLPバーンのサイズを決定するため、特定の USDC 支払いを満たすためにプロトコルがバーンしなければならないLPトークンの数は、請求時に固定されていないリザーブ値に依存します。

攻撃の分析

以下の分析はトランザクション 0xbb5b85...41c3588 と 0x70bbe0...b3315d6 に基づいています。

ステップ1：ブロック 113613923 において、攻撃者はフラッシュローンで借りた資金を使用して、LPD/USDCペアで大規模な USDC から LPD へのスワップを実行しました。これによりプールの LPD リザーブが減少し、LPD.price() が返すスポット価格が上昇しました。
ステップ2：価格が水増しされている間、攻撃者は buy() を呼び出して過大なオーダーを開設しました。操作されたスポット価格で評価されたことで、この預け入れは 140,324,732 というUSD元本で記録されました。

ステップ3：次のブロック 113613924 において、攻撃者はプロトコルのイシュー境界を越えました。経過したのは1ブロックのみでしたが、プロトコルは各イシュー変更を1日の会計期間として扱うため、水増しされた元本に対する1期間分の利息が請求可能になりました。
ステップ4：請求トランザクションにおいて、攻撃者は PoolManager を通じて 730,607.755349 USDC を借り、3,440.992868 USDC をLPD/USDCペアに直接転送し、sync() を呼び出しました。元のリザーブ状態では、水増しされた利息を満たすのに LpdFi が保有するLPトークン以上の量が必要となり、償還はリバートしていたでしょう。ペアの記録された USDC リザーブを 718,619.888284 から 722,060.881152 に引き上げることで、攻撃者は removeLp() がバーンする必要のあるLP量を削減し、プロトコルの実際のLPバランス内に収めました。

ステップ5：攻撃者は claimInterest(0) を呼び出しました。水増しされた元本により、1イシューで 701,623.66 USDC の請求可能な利息が生じました。リザーブ操作後、removeLp() はわずか 1,678,049.359669 のLPトークンをバーンすればよくなり、これは LpdFi が保有する全LPバランスとほぼ完全に一致していました。プロトコルはLP総供給量の約97%をバーンし、693,529.790711 USDC を攻撃者に転送しました。攻撃者はフラッシュローンを返済し、利益を引き出しました。

結論

このインシデントは、操作可能なAMMスポットリザーブをオーダー会計と償還の両方の真実のソースとして使用したことに起因しています。評価と償還は同じライブプールを読み取る独立した操作として扱われていたため、操作された価格で記録された元本は、プールの実際の裏付けと照合されることはありませんでした。

プロトコルはオーダー元本や出金会計の真実のソースとしてライブAMMリザーブを使用すべきではありません。より安全な設計では、スポット評価ではなく、鮮度と偏差チェックを伴う時間加重平均価格など、操作耐性のある価格ソースを通じて各預け入れを評価し、ポジションが実際に拠出したバッキング以上を請求がバーンできないよう、償還前にソルベンシーチェックを強制します。

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

Moke Token

2026年8月3日、BNBチェーン上のMoke Tokenが、スポット価格依存と重複したLP会計の組み合わせにより、約$906Kの被害を受けました。攻撃者はスポット価格を操作して請求可能な MOKE の量を水増しし、それをLP配当コントラクトに転送し、配当プロセスをトリガーして MOKE を BNB に売却し、その後重複したLPレコードを通じてその BNB を回収しました。

背景

Moke TokenはBNBチェーンのエコシステムで、ユーザー参加、遅延 MOKE リリース、LPリワード、紹介報酬を中心に構築されています。ユーザーは USDT と AC で参加します。MOKE をすぐに受け取る代わりに、各参加により MokeRelease が管理する将来の MOKE リリースが付与され、時間とともに請求可能になります。

ユーザーが請求すると、コントラクトは決済された MOKE/USDT 価格を使用してリリースされた USDT 価値を MOKE に変換し、対応する MOKE をリザーブプールからユーザーに転送します。これらのリリースされたトークンはデフォルトで制限されており、流動性追加に使用されるコントラクトなど、認可されたハンドラーアドレスにのみ転送できます。LPトークンを保有するユーザーは、LP持分に基づいてプロトコルの税金・配当プールから BNB の分配を受け取ります。

脆弱性の分析

バグのあるコントラクトは 0x684d...b302a7 と 0x5ae5...eba377 です。

第一の根本原因はスポット価格への依存です。getMokeUsdtPrice() は WBNB/USDT と WBNB/MOKE ペアから MOKE/USDT 価格を導出しており、操作耐性のある価格ソースがありません：

第二の根本原因は重複したLP会計です。_syncUserLP() は lpToken.balanceOf(user) を読み取って userLPRecord[user] に記録することでユーザーのLPバランスを記録します。更新が手動でトリガーされ、現在のバランスのみをキーとしているため、同じLPトークンを複数のアドレスに移動してそれぞれで同期させることができ、記録された総LPバランスとそれが得る配当報酬が水増しされます：

攻撃の分析

以下の分析はトランザクション 0xc0f1df...e26154 と 0x077604...756a8f に基づいています。

ステップ1：エクスプロイトの約10日前、攻撃者は MokeVault の participate 関数に USDT を預けることでリリースクォータを準備し、1日あたり5.5%でアンロックされる 45,000 USDT 相当の MOKE リリースクォータを取得しました。

ステップ2：攻撃者は MOKE/WBNB LPトークンをミントし、MokeLPDividend の syncUserLP を呼び出してLPバランスを記録した後、同じLPトークンを別のアドレスに転送して同期を繰り返し、1セットのトークンに対して重複したLPレコードを作成しました。

ステップ3：攻撃者はフラッシュローンを使用して大量の BNB を借り、WBNB/USDT ペアで USDT にスワップして USDT のスポット価格を押し上げました。攻撃者はその後 MokeRelease の MOKE 価格を更新し、決済された MOKE 価格が急落しました。

ステップ4：操作された MOKE 価格を使用して、攻撃者は MokeRelease で claim を呼び出し、24,766 USDT 相当のクォータを MOKE トークンに換金し、クォータの実際の価値をはるかに超える MOKE を受け取りました。

ステップ5：攻撃者はリリースされた MOKE をホワイトリストに登録された MokeLPDividend コントラクトに転送し、distributeDividend を呼び出して MOKE を BNB に売却しました。攻撃者は重複したLPバランスを記録したアドレスを使用して claimDividend を呼び出し、分配された BNB を回収し、合計 1,546 BNB を受け取りました。