在過去一週(2026/08/03 - 2026/08/09),以下 2 起值得關注的安全事件被列為重點,涉及總損失約 $1.6M。
| 日期 | 事件 | 類型 | 預估損失 |
|---|---|---|---|
| 2026/08/03 | LpdFi | 價格操縱 | ~$697K |
| 2026/08/03 | Moke Token | 價格操縱與帳務錯誤 | ~$906K |
- LpdFi 之所以被選中,是因為它展示了使用可操縱的 AMM 儲備同時用於倉位估值與利息兌付的系統性風險。攻擊者首先透過現貨價格操縱來膨脹已記錄的本金,然後透過直接捐贈與
sync()來改變資金池儲備,使超額利息索賠得以執行。這突顯了在整個倉位生命週期中驗證償付能力的重要性,而不是將存款估值、利息計算和贖回視為獨立操作。 - Moke Token 之所以被選中,是因為它展示了不同帳務機制中的漏洞如何被組合成單一的獲利攻擊。攻擊者操縱現貨價格以膨脹可索賠的
MOKE數量,透過將相同的 LP 代幣跨多個地址同步來複製 LP 獎勵記錄,並透過分紅系統將所得代幣轉換為可提取的BNB。這突顯了使用抗操縱價格來源以及保持獎勵帳務與實際代幣持有情況同步的重要性。
Web3 最佳安全審計機構
在上線前驗證設計、程式碼與業務邏輯
每週精選:LpdFi 協議
此事件被選為精選,因為相同的可操縱 AMM 狀態同時控制了負債的創建和資產的贖回。這說明了為何協議必須在完整的倉位生命週期中驗證償付能力,而不是將存款估值、利息累計和贖回視為獨立步驟。
2026 年 8 月 3 日,BNB Chain 上的 LpdFi 協議遭到攻擊,損失約 $697K,資金從 LPD/USDC PancakeSwap 交易對中被抽乾。LpdFi 從同一個即時 PancakeSwap 交易對中同時推導倉位的記錄價值及其後續利息支付,因此操縱該交易對會同時扭曲兩者。攻擊者開設了一個遠超實際價值的倉位,等待利息累計,然後調整交易對的儲備,使超額利息索賠得以支付,幾乎抽乾了協議持有的所有流動性。
背景
LpdFi 是一個圍繞 LPD 代幣構建的收益協議。用戶透過存入 LPD 來創建倉位。在存款時,協議使用當前 LPD/USDC PancakeSwap 現貨價格對存款進行估值,並將結果儲存為 uAmount,即訂單的以美元計價的本金。訂單按期次累計利息,每個期次為一個每日帳務週期,協議根據已記錄的本金為每個訂單設定總利息上限。
當用戶索賠利息時,協議透過使用 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 代幣數量:

因此兩個不變量被打破。首先,由於記錄的本金源自現貨價格,可能記錄遠大於存款實際價值的本金,從而提高利息上限。其次,由於 removeLp() 根據即時儲備計算 LP 燃燒量,協議為滿足給定 USDC 支付所需燃燒的 LP 代幣數量,取決於在索賠時並不固定的儲備值。
攻擊分析
以下分析基於交易 0xbb5b85...41c3588 和 0x70bbe0...b3315d6。
-
步驟 1:在區塊
113613923中,攻擊者使用閃電貸資金在 LPD/USDC 交易對中進行大量USDC兌LPD的交換。這減少了資金池的LPD儲備,並提高了LPD.price()返回的現貨價格。 -
步驟 2:在價格被膨脹期間,攻擊者呼叫
buy()開設了一個超額訂單。以操縱後的現貨價格估值,存款以 USD 本金140,324,732被記錄。

-
步驟 3:在下一個區塊
113613924中,攻擊者跨越了協議的期次邊界。儘管只經過了一個區塊,協議將每次期次變更視為一個每日帳務週期,因此膨脹本金的一個期次利息變得可索賠。 -
步驟 4:在索賠交易中,攻擊者透過
PoolManager借入730,607.755349USDC,直接將3,440.992868USDC轉入 LPD/USDC 交易對,並呼叫sync()。在原始儲備狀態下,膨脹的利息所需燃燒的 LP 代幣將超過LpdFi持有的數量,因此贖回將會回滾。透過將交易對記錄的USDC儲備從718,619.888284提高至722,060.881152,攻擊者減少了removeLp()需要燃燒的 LP 數量,使其在協議的實際 LP 餘額範圍內。

- 步驟 5:攻擊者呼叫
claimInterest(0)。膨脹的本金為一個期次產生了701,623.66USDC的可索賠利息。在儲備操縱之後,removeLp()只需燃燒1,678,049.359669個 LP 代幣,幾乎恰好是LpdFi持有的全部 LP 餘額。協議燃燒了約 97% 的總 LP 供應量,向攻擊者轉移了693,529.790711USDC,攻擊者還清了閃電貸並提取了利潤。
結論
此事件源於將可操縱的 AMM 現貨儲備用作訂單帳務和贖回的真實來源。估值和贖回被視為從同一即時資金池讀取數據的獨立操作,因此以操縱價格記錄的本金從未與資金池的實際支撐進行核對。
協議不應將即時 AMM 儲備用作訂單本金或提款帳務的真實來源。更安全的設計是透過抗操縱的價格來源對每筆存款進行估值,例如帶有新鮮度和偏差檢查的時間加權平均價格,而非現貨估值,並在贖回前執行償付能力檢查,確保索賠永遠不會燃燒超過倉位實際貢獻的支撐。
本週更多事件
Moke Token
2026 年 8 月 3 日,BNB Chain 上的 Moke Token 遭到攻擊,透過現貨價格依賴結合重複 LP 帳務損失約 $906K。攻擊者操縱現貨價格以膨脹可索賠的 MOKE 數量,將其轉入 LP 分紅合約,觸發分紅流程將 MOKE 出售為 BNB,然後透過重複的 LP 記錄收集該 BNB。
背景
Moke Token 是一個圍繞用戶參與、延遲 MOKE 釋放、LP 獎勵和推薦激勵構建的 BNB Chain 生態系統。用戶以 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來準備釋放額度,獲得了價值45,000 USDT的MOKE釋放額度,以每天 5.5% 的速度解鎖。

- 步驟 2:攻擊者鑄造了
MOKE/WBNBLP 代幣,並在MokeLPDividend中呼叫syncUserLP記錄 LP 餘額,然後將相同的 LP 代幣轉移到另一個地址並重複同步,為同一組代幣創建了重複的 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。

結論
Moke Token 結合了兩個獨立的缺陷:一個可以透過閃電貸移動的現貨價格,以及將相同 LP 代幣重複計算的分紅帳務。兩者單獨存在的危害都不及兩者結合時那麼嚴重。
協議應避免在安全敏感的計算中使用瞬時現貨價格,而應使用抗操縱的來源。任何基於代幣餘額的帳務都必須與餘額變更同步更新,以防止相同代幣被跨多個地址重複計算。



