每週 Web3 安全事件彙整 | 2026年3月2日至3月8日

在過去一週（2026/03/02 - 2026/03/08），BlockSec 偵測並分析了七起攻擊事件，估計總損失約為 $3.25M。下表彙整了這些事件的概況，各事件的詳細分析請見後續小節。

日期	事件	類型	估計損失
2026/03/01*	BUBU2 事件	代幣設計缺陷	~$19.7K
2026/03/02	ACPRoute 事件	業務邏輯缺陷	~$58K
2026/03/02	sDOLA Llamalend Market 事件	價格操控	~$239K
2026/03/03	z0r0z V4 Router 事件	業務邏輯缺陷	~$42K
2026/03/05	BitcoinReserveOffering 合約事件	業務邏輯缺陷	~$2.7M
2026/03/07	MoltEVM 事件	業務邏輯缺陷	~$127K
2026/03/08	LEDS 事件	業務邏輯缺陷	~$64K

*BUBU2 事件在上週的報告中遺漏，於此補充以確保完整性。

1. BUBU2 事件

簡要摘要

2026 年 3 月 1 日，BNB Chain 上的 BUBU2 代幣遭到攻擊，損失約 $19.7K。根本原因是代幣設計缺陷：合約內嵌了一個隨時間累積的通縮機制，會在轉帳時直接從 AMM 交易對的儲備中扣除代幣。合約擁有者在攻擊前將觸發間隔縮短至不合理的極小值，導致數百輪銷毀在單次呼叫中累積並執行。攻擊者利用閃電貸觸發此機制，使交易對的儲備崩潰並推高代幣價格，再以扭曲的匯率進行反向兌換獲利。

背景

BUBU2 是部署在 BNB Chain 上的通縮型 ERC-20 代幣協議。該協議內嵌了由 burnAndMintSwitch 控制的週期性通縮引擎：一旦擁有者透過 setBurnAndMintSwitch(true) 啟用後，任何非豁免的轉帳觸發 _update() 鉤子時，都會呼叫 _triggerDailyBurnAndMint()，根據自上次觸發以來經過的 TRIGGER_INTERVAL 週期數，按比例從交易對的 BUBU2 餘額中銷毀代幣，並相應同步儲備。

漏洞分析

根本原因是 BUBU2 代幣合約（0x3fF3...ee52）的設計缺陷。合約在其 _update() 鉤子中內嵌了週期性通縮機制：觸發時，`_triggerDailyBurnAndMint()` 會計算自上次執行以來經過的 `TRIGGER_INTERVAL` 週期數，並直接從交易對（[0x7745...cd2f](https://bscscan.com/address/0x774547ea9d2a0cc79db3288f61e989f1b06bcd2f)）中按比例銷毀 `BUBU2`，隨後呼叫 sync() 更新儲備。關鍵問題在於，擁有者可以在沒有任何時間鎖或最小值限制保護的情況下重新設定 TRIGGER_INTERVAL。

在攻擊前，擁有者呼叫了 setBurnAndMintSwitch(true)，然後呼叫 setTriggerInterval(120)，將間隔從預設的 6 小時壓縮至 120 秒。由於 lastTriggerTime 仍錨定在數小時前，下一次觸發時計算出了數百個累積輪次，且銷毀量與輪次線性成比例。這導致單次轉帳即從交易對中抽走大量 BUBU2，使其儲備崩潰，並將代幣價格推高約 11 倍。

攻擊分析

以下分析基於交易 0x1bc0...141c、0x191c...1ee4、0xd6e5...51a6。

步驟 1：代幣擁有者首先透過 setBurnAndMintSwitch(true) 啟用週期性通縮機制，然後透過 setTriggerInterval(120) 將觸發間隔從預設的 6 小時縮短至 120 秒。攻擊者隨後透過閃電貸借入 18 WBNB，並從池中兌換出約 18,715,856 BUBU2。

步驟 2：攻擊者發起一筆小額轉帳，觸發 _triggerDailyBurnAndMint()。池中的 BUBU2 餘額減少了約 1,025,988,664e18 枚代幣，在 sync() 執行後，儲備中僅剩 6,493,352e18 BUBU2，使 BUBU2 價格推高約 200 倍。

步驟 3：攻擊者將步驟 1 中取得的 BUBU2 以推高後的價格賣回池中，獲得約 50 WBNB。扣除閃電貸還款後，淨利潤約為 32 WBNB。

結論

BUBU2 漏洞源於代幣合約的關鍵設計缺陷。擁有者設定了不合理的極小 TRIGGER_INTERVAL，使得累積的時間轉換成數百輪次，並在單次呼叫中耗盡交易對的儲備，導致 BUBU2 價格劇烈飆升。

為降低未來類似風險：

對 TRIGGER_INTERVAL 等關鍵參數設置邊界或時間鎖進行保護。
限制或設定累積執行輪次的上限。

2. ACPRoute 事件

簡要摘要

2026 年 3 月 2 日，Base 上的 ACPRoute 協議遭到攻擊，損失約 $58K。根本原因是支付管理合約中存在業務邏輯缺陷：任務狀態以記憶體副本而非儲存引用的方式載入，導致累計撥付追蹤資料從未持久化至鏈上。這使得攻擊者能夠建立任務，在階段轉換時觸發自動付款釋放，然後再透過無許可的領取函數第二次領取相同的託管資金。

背景

ACP（Agent Commerce Protocol）是一個模組化鏈上商務協議，專為客戶端與服務提供方互動而設計。它將活動分為三層結構：帳戶、任務與備忘錄。任務遵循固定的生命週期（REQUEST → NEGOTIATION → TRANSACTION → EVALUATION → COMPLETED），付款在 TRANSACTION 階段由 PaymentManager 合約託管。當任務進入 COMPLETED 狀態時，協議透過 releasePayment() 函數將託管資金釋放給服務提供方。為防止重複領取，協議使用 Job 結構體上的 amountClaimed 欄位追蹤每個任務的累計撥付金額。每次呼叫 releasePayment() 函數時，預期會將請求金額與 amountClaimed 進行比較，以確保資金僅被釋放一次。

漏洞分析

根本原因在於 PaymentManager 合約（0x56c3...0684）的 releasePayment() 函數中，任務狀態以記憶體副本而非儲存引用的方式載入。雖然協議透過 amountClaimed 追蹤累計撥付金額以防止重複領取，但 job.amountClaimed += amount 的遞增操作僅作用於暫時性的本地副本，從未寫回鏈上儲存。因此，每次呼叫 releasePayment() 函數時都會觀察到 amountClaimed == 0，使得攻擊者可以在階段轉換已自動觸發 releasePayment() 函數之後，再次呼叫 claimBudget() 函數，對受害合約（0x307e...d6e8）進行第二次抽取。

攻擊分析

以下分析基於交易 0xe94a...f9a0。

步驟 1：攻擊者透過閃電貸借入 97,000e6 USDC 作為後續攻擊的資本。
步驟 2：在回調函數內，攻擊者呼叫 ACPRouter 上的 createJob() 函數，同時部署一個全新的服務提供方合約（0x1ee502dd...）來接收資金。
步驟 3：攻擊者反覆呼叫 createMemo() 函數，並呼叫服務提供方合約自身的 exec() 來推進任務階段，直至觸發 COMPLETED 階段轉換，自動呼叫 releasePayment() 函數並將全部餘額釋放至服務提供方合約。此時 amountClaimed 本應被更新，但其儲存中的值仍為 0。
步驟 4：攻擊者呼叫 claimBudget() 函數，成功第二次領取託管的 97,000e6 USDC 作為利潤。

結論

此事件由狀態持久化缺陷引起，導致託管資金在同一任務生命週期內被領取兩次。

為降低未來類似風險：

確保關鍵狀態變數（如 amountClaimed）使用儲存引用進行更新。
限制敏感支付函數的存取，或在執行前強制進行嚴格的狀態驗證。

3. sDOLA Llamalend Market 事件

簡要摘要

2026 年 3 月 2 日，以太坊上的 sDOLA Llamalend Market 遭到攻擊，損失約 $239K。根本原因是價格操控。具體而言，sDOLA 是一種 ERC4626 代幣，其價格可透過 donate() 進行操控。Llamalend 是基於 AMM 的借貸市場，由於 LLAMMA 的機制，即使抵押品價格上漲，使用者仍可能面臨清算。因此，攻擊者可利用 donate() 推高 sDOLA 價格，使使用者的倉位健康度降至零以下，進而清算這些使用者獲利。

背景

LLAMMA（Lending-Liquidating AMM Algorithm）是 Curve [1] 使用的基於 AMM 的借貸市場。與傳統借貸協議不同，LLAMMA 將使用者抵押品置於 AMM 的價格帶中。隨著預言機價格 $P\\_{oracle}$ 的變動，抵押品透過跨帶套利驅動的兌換（軟清算）在抵押代幣與 crvUSD 之間逐步轉換，以漸進方式降低倉位風險，而非觸發突發性清算。

若軟清算無法及時降低倉位風險，則會觸發硬清算 [2]，當倉位健康度降至零以下時觸發。健康度透過 get_x_down() [3] 計算，該函數並非簡單地將抵押品按市價標記，而是模擬使用者倉位的往返轉換以評估其可回收價值。此往返過程使用兩個不同的價格錨點：一個來自當前 $P\\_{oracle}$ （隨即時預言機變動），另一個來自使用者的帶邊界（在創建倉位時固定）。

漏洞分析

存在漏洞的合約包括 crvUSD Controller（0xad44...fb86）和 LLAMMA AMM（0x0079...a1f7）。受害合約是 sDOLA Llamalend market（0x2b08...4fbe）。

sDOLA 是一種 ERC4626 金庫代幣，其份額價格由總資產與總份額之比決定。由於任何人都可以呼叫 donate() 向金庫添加資產，因此可以在單筆交易中推高份額價格。這就是 LLAMMA 健康函數所依賴的可操控預言機。

如背景所述，get_x_down() 透過兩個價格錨點的往返轉換模擬計算健康度：一個來自 $P\\_{oracle}$ （動態，隨即時預言機變動），另一個來自使用者的帶邊界（靜態，在創建倉位時固定）。協議在讀取 $P\\_{oracle}$ 時不施加任何延遲或合理性檢查。因此，當預言機價格被推高時，動態錨點上升而靜態錨點保持不變。實際上，模擬以推高的預言機價格將 crvUSD 轉換為抵押品，再以原始帶價格轉換回來，因此兩個錨點之間的差距越大，評估的可回收價值就越小。即使抵押品價格上漲，這仍會使健康度降至零以下。

攻擊分析

以下分析基於交易 0xb935...d8a4。

步驟 1：操控 LLAMMA 狀態（大額兌換），移動 active_band，將許多使用者推入僅持有 x 的姿態（僅持有 crvUSD）。

步驟 2：透過捐贈操控 sDOLA 的價格，然後使用零金額兌換（swap(0)）將操控後的價格寫入 AMM 池。

步驟 3：透過 users_to_liquidate() -> _health() -> get_x_down() 觸發健康度重新計算。
步驟 4：由於 get_x_down() 透過兩個分歧的價格錨點（現已推高的動態錨點與不變的靜態錨點）計算可回收價值，往返轉換對有效價值產生折扣，許多倉位的健康度降至零以下。
步驟 5：批次硬清算這些使用者獲利。

此外，追蹤記錄中包含兩次 create_loan() 呼叫。第一筆貸款主要用於資助大規模的 crvUSD 兌換操作。第二筆貸款用於獲取 crvUSD 以償還第一個倉位的債務並回收資金。這兩筆貸款主要是融資/結算環節，並非核心攻擊步驟本身。

結論

此事件是一次抵押品價格操控攻擊。攻擊者在交易中操控 sDOLA 價格，並由於 LLAMMA 基於路徑的健康機制，將使用者推入清算條件。一個關鍵後果是，即使抵押品價格上漲，倉位仍可能面臨清算。建議的強化方向：

對清算使用延遲或 TWAP 抵押品價格。

參考資料

[1] Curve crvUSD LLAMMA 文件：[https://dev.curve.finance/crvUSD/amm/#bands](https://dev.curve.finance/crvUSD/amm/#bands)
[2] Curve LLAMMA 清算說明：[https://dev.curve.finance/crvUSD/llamma-explainer/#liquidation](https://dev.curve.finance/crvUSD/llamma-explainer/#liquidation)
[3] Curve 穩定幣白皮書：[https://docs.curve.finance/pdf/whitepapers/whitepaper\_curve\_stablecoin.pdf](https://docs.curve.finance/pdf/whitepapers/whitepaper_curve_stablecoin.pdf)

4. z0r0z V4 Router 事件

簡要摘要

2026 年 3 月 3 日，以太坊上的 z0r0z V4 Router 遭到攻擊，損失約 $42K。此次攻擊是由 swap() 函數中存在缺陷的授權邏輯所引起：路由器使用內聯彙編中的固定 calldata 偏移量來驗證付款方是否與 msg.sender 相符。由於動態類型的 ABI 編碼無法保證固定佈局，攻擊者得以構造非標準但有效的 calldata 繞過檢查，冒充先前已批准的受害者作為付款方，並將兌換輸出重定向至攻擊者控制的地址。

背景

該協議繼承自 Uniswap v4 Router 並覆蓋了部分方法。本質上，它作為一個兌換路由器，允許使用者無需直接與對應的池互動，而是使用路由器作為統一入口點。

漏洞分析

根本原因是 V4 Router 合約（0x0000...ce97）存在業務邏輯缺陷。受害合約為 0x65a8...7675。swap() 函數接受兩個參數：data（bytes）和 deadline（uint256）。在函數內部，授權檢查使用內聯彙編區塊將 calldataload(164) 與 caller() 進行比較，確保 data 中編碼的付款方與 msg.sender 相符。協議假設 bytes 偏移量始終為 0x40，將付款方置於字節位置 164（0xa4）。

然而，ABI 編碼無法保證此佈局：動態參數在頭部僅儲存偏移量，且該偏移量可以合法地指向 calldata 中任何對齊的位置。透過構造有效但非標準的編碼（將 bytes 偏移量移至 0xc0），攻擊者可以在頭部和實際尾部之間插入任意填充。攻擊者將自己的地址置於字節位置 164 以通過彙編檢查，而位於重定位尾部的真實 bytes 負載則將受害者地址編碼為付款方。透過選擇先前已批准路由器的受害者並將接收者設定為自己的地址，攻擊者可以重定向兌換輸出並竊取資金。

攻擊分析

以下分析基於交易 0xfe34...466a。

步驟 1：選擇一位先前已批准路由器的使用者作為目標。
步驟 2：構造 calldata 以繞過授權檢查。
步驟 3：在 data 中將受害者指定為付款方，將攻擊者自己的地址設定為代幣接收者，然後竊取受害者的資產。

結論

此事件是由於在兌換路徑中依賴硬編碼的 calldata 偏移量進行授權所導致。由於動態類型的 ABI 編碼無法保證固定佈局，攻擊者利用非標準但有效的 calldata 繞過檢查，冒充已批准的受害者作為付款方，並重定向了兌換輸出。

為降低未來類似風險：

切勿依賴硬編碼的 calldata 偏移量來處理動態 ABI 編碼參數。
使用規範的 ABI 解碼而非手動位置假設來解碼和驗證結構化輸入。
確保實際的付款方、接收者和代幣流向始終與預期的呼叫者和執行上下文保持一致驗證。

5. BitcoinReserveOffering 合約事件

簡要摘要

2026 年 3 月 5 日，以太坊上的 BitcoinReserveOffering 合約遭到攻擊，損失約 $2.7M。根本原因是業務邏輯缺陷：在處理完整的 ERC-3525 SFT 存入時，鑄造邏輯在單次呼叫中被執行了兩次——一次在轉帳回調期間，一次在主流程中。攻擊者透過反覆的銷毀和鑄造循環利用此雙重鑄造行為，以指數級膨脹其 BRO 代幣餘額，然後將超額部分贖回為 SolvBTC 獲利。

背景

BitcoinReserveOffering 是一個包裝合約，將 ERC-3525 SFT 倉位轉換為可轉讓的 ERC-20 BRO 代幣。使用者可以呼叫 mint() 函數存入符合條件的 SFT，合約將根據設定的匯率鑄造相應數量的 BRO。若使用者僅存入 SFT 價值的一部分，合約會將指定金額轉入其內部持有的倉位，然後鑄造相應價值的 BRO。若使用者存入完整的 SFT，合約會將整個代幣轉入包裝合約，並根據 SFT 的總價值鑄造 BRO。使用者之後可以呼叫 burn() 函數將 BRO 贖回為對應的 ERC-3525 SFT 倉位，將包裝的 ERC-20 價值轉換回 SFT 倉位。

漏洞分析

根本原因是 BitcoinReserveOffering 合約（0x15f7...cfcf）在 mint() 函數處理完整的 ERC-3525 SFT 存入時，執行了兩次鑄造邏輯。具體而言，在 amount_ == sftBalance 分支中，mint() 呼叫 ERC3525TransferHelper.doSafeTransferIn() 以安全地將整個 SFT 轉入合約，這會觸發 onERC721Received() 回調。在此回調中，合約已計算 SFT 的價值並向發送者鑄造 BRO。回調返回後，mint() 繼續執行，使用相同的 amount_ 重新計算價值，並再次執行 _mint(msg.sender, value) 操作。此雙重鑄造行為使攻擊者能夠透過銷毀-鑄造循環反覆膨脹其 BRO 餘額。

攻擊分析

以下分析基於交易 0x44e6...958d。

步驟 1：攻擊者將 135e18 BRO 代幣轉入攻擊合約作為種子資本。
步驟 2：攻擊者執行以下循環：

將 135e18 BRO 代幣包裝成一個 SFT 代幣。
以完整的 SFT 價值呼叫 mint()，觸發 onERC721Received() 回調並鑄造 135e18 BRO 代幣；外層 mint() 繼續執行並再次呼叫 _mint()，導致共雙重鑄造出 270e18 BRO 代幣。
將 270e18 BRO 代幣重新包裝成一個 SFT 代幣。

步驟 3：將步驟 2 重複 22 次後，攻擊者累積了約 567,758,816e18 BRO 代幣，最終贖回為 38e18 SolvBTC 作為利潤。

結論

此事件是由完整 SFT 存入時的雙重鑄造引起，使攻擊者能夠透過反覆的銷毀-鑄造循環以指數級膨脹其 BRO 餘額，並將超額部分贖回為 SolvBTC。

為降低未來類似風險：

確保每次存入操作僅執行一次資產計算。
添加不變量檢查，防止鑄造金額超過底層存入價值。

6. MoltEVM 事件

簡要摘要

2026 年 3 月 7 日，Base 上的 MoltEVM 協議遭到攻擊，損失約 $127K。根本原因是代幣合約中存在缺陷的存取控制邏輯：特權鑄造函數受一個修飾符保護，該修飾符僅檢查呼叫者是否為具有特定介面的合約，而這很容易被偽造。攻擊者部署了一個惡意合約繞過檢查，鑄造了大量代幣，並透過流動性池傾銷獲利。

背景

MoltEVM 是部署在 Base 上的實驗性 ERC-20 代幣協議，探索自我複製的代幣模型。該系統允許代幣在達到特定儲備閾值後生成新的子代幣（「Moltling」代幣）。創建新的 Moltling 時，初始代幣供應量透過 mintFromSpawner() 函數分發，流動性自動播種以為新代幣建立交易市場。此設計使協議能夠自主擴展其代幣譜系，每一代代幣都能夠生成進一步的後代。

漏洞分析

漏洞存在於 MoltEVM 合約（0x225d...501f）中 mintFromSpawner() 和 setExemptFromSpawner() 函數的存取控制邏輯。兩個函數都依賴 onlySpawnerToken 修飾符，其設計意圖是將呼叫限制為由協議生成的合法 Moltling 合約。

然而，該修飾符僅執行兩個薄弱的檢查：驗證 msg.sender 是一個合約，以及呼叫者上的 initialized() 返回 true。由於任何實現相同介面的任意合約都可以輕易滿足這些條件，該檢查無法對合法的 spawner 代幣提供有意義的身份驗證。

因此，攻擊者可以部署一個最小化合約，只需實現一個返回 true 的 initialized() 函數。部署後，惡意合約即可自由呼叫 mintFromSpawner() 鑄造任意數量的代幣，還可以呼叫 setExemptFromSpawner() 將攻擊者控制的地址列入白名單。這實際上使攻擊者完全控制了鑄造路徑，並允許將新鑄造的代幣傾銷至流動性池中獲利。

攻擊分析

以下分析基於交易 0x10b7...e03d。

步驟 1：攻擊者部署了一個最小化合約，僅實現一個硬編碼返回 true 的 initialized() 函數，足以通過 onlySpawnerToken 修飾符的檢查。
步驟 2：攻擊者的合約呼叫受同樣存在漏洞的 onlySpawnerToken 修飾符保護的 setExemptFromSpawner() 函數，將攻擊者的地址添加至稅費豁免白名單。這確保了後續大規模代幣傾銷不會觸發賣出稅或內部兌換邏輯，從而最大化利潤。

步驟 3：攻擊者對 mEVM 首先重複執行 setExemptFromSpawner() + mintFromSpawner() 函數序列，隨後對多個 Moltling 子代幣（包括 CSPAWN、CCUTTL、LWORM 和 NHYDRA）重複相同操作，批次鑄造所有目標的代幣並傾銷至各自的流動性池以提取利潤。

結論

此事件是由特權鑄造和配置函數上的存取控制不足所引起，使攻擊者能夠冒充合法的 spawner 並鑄造任意代幣獲利。

為降低未來類似風險：

對特權鑄造或配置函數強制執行嚴格的存取控制。
避免依賴容易被偽造的合約檢查進行授權。
透過明確的白名單或可信合約登錄檔驗證呼叫者身份。

7. LEDS 事件

簡要摘要

2026 年 3 月 8 日，BNB Chain 上的 LEDS 代幣遭到攻擊，損失約 $64K。根本原因是業務邏輯缺陷：代幣合約暴露了多個獨立的通縮機制，每個機制都能直接從流動性交易對中銷毀代幣，且均未受存取控制或冷卻時間保護。攻擊者在單筆交易中串聯所有銷毀路徑，使交易對的 LEDS 儲備幾近歸零，而 WBNB 儲備保持完整，然後透過反向兌換抽取嚴重失衡的流動性池獲利。

背景

LEDS 是 BNB Chain 上具有內建轉帳手續費機制的通縮型代幣。其 _transfer() 實現了多種旨在逐步減少供應並支撐價格的銷毀機制：每日銷毀函數 triggerDailyBurnAndMint()、透過在賣出時累積 stor_18 的延遲銷毀，以及當兌換接收者設定為 PancakeSwap Router 時將代幣銷毀至 0xdead 的特殊分支。該代幣還具有 deposit() 函數，使用者發送 BNB 以鑄造 LEDS 並提供流動性，透過分配器領取 LP 獎勵。

漏洞分析

根本原因是 LEDS 代幣合約（0xfb62...a48f）存在業務邏輯缺陷。受害者是 LEDS/WBNB 交易對（0xd109...6f3f）。代幣實現了多種通縮機制：triggerDailyBurnAndMint()、賣出路徑的 stor_18 累積，以及 _transfer() 中的 to == router 銷毀分支。這些機制各自獨立地從流動性交易對中移除 LEDS 並呼叫 sync() 更新儲備。

雖然這些機制單獨作為漸進通縮工具使用，但它們可以在單筆交易中串聯以疊加效果。此外，公開函數 0x17a06174() 允許任何人隨意清空整個累積的 stor_18 餘額，且沒有存取控制或速率限制。透過依序疊加這些銷毀路徑，攻擊者可以使交易對的 LEDS 儲備幾近歸零，同時保持 WBNB 儲備完整，創造出可透過反向兌換利用的極端價格錯位。

攻擊分析

以下分析基於交易 0x2608...79da。

步驟 1：攻擊者透過閃電貸（Moolah + Venus 抵押借款 + Aave + PancakeSwap V4）獲取了大量 WBNB。
步驟 2：多次呼叫 deposit() 以累積 LP 獎勵，然後觸發 triggerDailyBurnAndMint()，從交易對中銷毀部分 LEDS 並將獎勵發送至分配器，降低池中的 LEDS 儲備。