Web3 每週安全事件摘要 | 2026 年 4 月 6 日 – 4 月 12 日

在過去的一週（2026/04/06 - 2026/04/12）中，BlockSec 檢測並分析了四起攻擊事件，總估計損失約為 $928.6K。下表總結了這些事件，後續章節則提供了各案例的詳細分析。

*Denaria 事件未包含在上週的報告中，此處納入以確保完整性。

從本週開始，我們將在每份報告的頂部重點介紹一個事件。選擇標準不一定基於損失金額，也可能基於其新穎的協議設計、巧妙的攻擊技術或對社群更廣泛的啟示。

每週重點：Denaria 事件

永續 DEX 協議 Denaria 引入了基於複雜代碼邏輯的新穎會計機制。然而，審計後的代碼重構引入了一種捨入不對稱性，可能產生一個微妙的邊緣情況（負值），該負值最終觸發了不安全的轉型，導致了巨大的價值提取。

2026 年 4 月 5 日，位於 Linea 鏈上的永續 DEX Denaria 遭到攻擊，損失約 $165.6K。根本原因是 getLpLiquidityBalance() 函數中兩個缺陷的疊加：審計後的 LP 餘額會計重構引入了捨入不對稱性，可能導致中間值出現輕微為負的情況；而一次不安全的 int256 到 uint256 轉型則將該負值靜默包裝為接近最大的無符號整數，而非觸發回滾。攻擊者通過單邊 LP 存款和多頭交易利用了這一漏洞，隨後從金庫中提取了人工膨脹的盈虧 (PnL)。

背景

Denaria 是 Linea 上一個圍繞動態虛擬 AMM 構建的永續 DEX，將交易和結算分為兩個組件。PerpPair 市場管理用戶倉位和 LP 會計，而 Vault 則持有抵押品並結算已實現的盈虧。

PerpPair 中的 LP 所有權並不以顯式的代幣餘額表示。相反，協議會從一個內部會計矩陣中重建每個 LP 的狀態，該矩陣由資產端 (asset side) 和穩定幣端 (stable side) 兩個記帳組件組成。資產端追蹤 LP 在資金池中對價格變動的敞口，而穩定幣端追蹤其在池中以穩定幣定值的份額。這兩個組件共同決定了 LP 的價值如何被追蹤和結算。

關鍵在於，這些組件並非以靜態快照形式存儲。每當交易發生時，PerpPair 會更新其全局流動性狀態，而每個 LP 重建後的餘額則是從累積的全局價值與該 LP 入口點快照之間的差額導出的。這種會計機制是在審計後的重構中引入的，旨在取代原有的基於份額的累加器。然而，重構後的減法路徑引入了一種捨入不對稱性，導致在特定的交易序列下，重建後的 LP 組件可能會變得輕微為負。

漏洞分析

存在漏洞的 PerpPair 合約 (0xb683...36ae17) 包含兩個疊加缺陷：

1. 重構會計中的捨入不對稱性。引入直接餘額追蹤的審計後重構，在減法重建路徑中產生了捨入不對稱性。在特定交易序列下，捨入後的全局累計價值可能會略小於 LP 的入口點快照，導致減法運算產生一個小的負值，而非歸零。理論上，該值應為零或接近零；這種不對稱性是特定於此重構實現的缺陷，而非減法會計的一般固有屬性。

2. 不安全的有符號轉無符號轉型。在 getLpLiquidityBalance() 中，重建的 LP 餘額組件從 int256 被轉型為 uint256，且未經驗證。在 Solidity 中，將負的 int256 轉型為 uint256 不會回滾，而是按 2^256 取模進行包裝，將像 -1 這樣的小負數變成接近最大的無符號整數 (2^256 - 1)。由於該重建後的餘額會進入 calcPnL() 進行結算，任何負數輸入都會被解釋為一個巨大的 LP 倉位，使攻擊者能夠實現虛假膨脹的利潤並耗盡金庫資金。

單個缺陷都不足以被利用。捨入不對稱性只產生輕微的負值，在正常的 int256 算術中僅代表微不足道的誤差。但當該負值到達未加防護的轉型過程時，它被包裝成了接近最大的無符號整數。隨後的邊界檢查將該值上限限制為該池的全部資產端流動性，有效地將溢出轉化為對市場整個資產端的索賠權。

攻擊分析

以下分析基於攻擊交易 0xcb0744...0c606447。

• 步驟 1：攻擊者通過 Aave 閃電貸借入了 60,000 USDC。

• 步驟 2：一個助手位址存入 30,000 USDC 作為抵押品，並新增了 19,980 穩定幣的純穩定幣 LP 倉位。通過僅在穩定幣端存款，該助手確保其資產端 LP 組件從接近零開始，使其更容易因捨入而滑入負值區域。

• 步驟 3：第二個助手位址存入 15,000 USDC 並開了 100,000 名義價值的多頭倉位，導致 liquidityM 更新，引入了關鍵的捨入誤差。相對於流動池的大名義價值放大了單次交易的捨入影響，使第一個助手的重建資產端餘額降至零以下。

• 步驟 4：第一個助手隨後調用 realizePnL()。在 LP 餘額重建期間，負的 lpAssetBalance 被包裝為接近最大的 uint256。這個大數值隨後被限制在市場的全部資產端流動性內，並產生了極度膨脹的利潤。實際上，協議誤認為該 LP 擁有市場的整個資產端。

• 步驟 5：攻擊者從金庫提取了膨脹後的盈虧。

該模式重複進行直到剩餘的金庫流動性被耗盡。償還閃電貸後，攻擊者實現了約 $165.6K 的利潤。

結論

該漏洞的根本原因是對有符號到無符號轉換缺少邊界驗證。即時修正非常簡單：使用 SafeCast.toUint256() 替換原始轉型，這會在輸入為負時回滾而非包裝。

更廣泛地說，此事件凸顯了跳過外部審計進行代碼重構的風險。根據 官方事故報告，捨入不對稱性是在最終外部審計完成後，團隊將原始累加器更換為直接餘額追蹤時引入的。雖然重構解決了溢出隱患，但產生了內部測試未能發現的新邊緣情況。當協議重構核心會計邏輯時，新的代碼路徑應被視為安全關鍵並進行重新審計，特別是當重建後的數值直接進入盈虧結算或提款邏輯時。

HB Token 事件

2026 年 4 月 7 日，BNB Chain 上具備內嵌買/賣鉤子 (hook) 的自訂 ERC-20 代幣 HB 遭到攻擊，損失約 $193K。根本原因是錯誤的獎勵結算邏輯：當觸發時，它會調用 swapBack()，直接從 PancakeSwap 交易對中移除 HB 儲備，然後調用 sync() 來重新計價。在攻擊者買光交易對中的大部分 HB 後，後續的 swapBack() 執行進一步降低了剩餘流動性並急劇拉高了現貨價格。隨後，攻擊者向被扭曲的資金池中出售極少量的 HB，換取不成比例的大量 USDT，並重複此循環直到交易對被耗盡。

背景

HB 是 BNB Chain 上的一種自訂 ERC-20 代幣，在 _transfer() 中內嵌了買賣鉤子。當用戶從 AMM 交易對購買時，_handleBuy() 會記錄成本基礎資訊。當用戶出售時，_handleSell() 根據交易對的狀態分為不同的稅收和結算路徑。

該代幣還包含一個可觸發 swapBack() 的獎勵結算機制。swapBack() 並非執行正常的路由中轉交換，而是直接將 HB 從 PancakeSwap 交易對轉移到 PROOF 位址，然後強制要求交易對通過 sync() 重新同步。這使合約能夠在普通 AMM 交易流程之外縮減交易對的 HB 儲備，並立即向上重新調整資金池的價格。

漏洞分析

HB 代幣合約 (0x62ce...87a4b0) 的核心漏洞在於 swapBack() 通過直接從 AMM 交易對而非國庫或通過路由中轉交換來獲取獎勵。由於 swapBack() 可以通過獎勵結算路徑訪問，一個非交易的代碼路徑就能直接改變交易對儲備並篡改現貨價格。

當交易對的 HB 儲備較低時，swapBack() 的調用會進一步減少剩餘的 HB 並放大價格扭曲，從而使以極高的價格出售少量 HB 成為可能。

攻擊分析

以下分析基於攻擊交易 0x19671f...d71594ed。

• 步驟 1：攻擊者從 Venus 借入了大量資金。

• 步驟 2：攻擊者將約 1,496 HB 轉入代幣合約，增加了合約的 HB 餘額，以便後續的 swapBack() 能從交易對中提取更多份額。

• 步驟 3：通過將極少量 HB 轉入 PancakeSwap 交易對，攻擊者觸發了 _swapAndLiquify()，將代幣合約持有的約 4,163 HB 交換為 10 USDT，同時增加了攻擊者可領取的 HB 獎勵。

• 步驟 4：攻擊者隨後花費 72,117,360 USDT 購買了 73,608,753 HB，導致交易對幾乎沒有剩餘的 HB 流動性。

• 步驟 5：接下來，攻擊者觸發了獎勵不足路徑。為滿足獎勵，代幣調用了 swapBack()，從 PancakeSwap 交易對中提取了額外的 HB 並強制執行 sync()，急劇推升了 HB 價格。

• 步驟 6：攻擊者直接將 USDT 轉入交易對以補充其 USDT 儲備，隨後以扭曲的價格僅出售 0.000582 HB 換取 37,582,322 USDT。

通過重複步驟 6 以扭曲的價格出售 HB 代幣，攻擊者從資金池中提取了幾乎所有的 USDT。

結論

HB 代幣事件說明了允許獎勵邏輯直接修改 AMM 儲備是多麼危險。影響儲備的函數絕不應從獎勵結算路徑中被訪問，協議應避免在安全敏感的控制流中將內部代幣餘額與 AMM 儲備會計混為一談。任何依賴於內部擾動資金池後的現貨 AMM 價格的設計，本質上都是容易受到價格操縱的。

Squid Multicall 事件

2026 年 4 月 7 日，一位 Squid 用戶在一項與授權相關的事件中損失了約 $517K（跨多條鏈）。用戶誤將授權給予了 SquidMulticall 合約，而非預期的 Squid Router 合約。這使得攻擊者能夠調用無需權限的 SquidMulticall.run() 函數來執行任意外部呼叫。因此，攻擊者可以使用任何撥給該合約的額度，針對曾給予其授權的用戶執行代幣 transferFrom() 呼叫。

背景

在 Squid 的正常流程中，用戶應授權 Squid Router，而 SquidMulticall 僅作為執行助手。該助手合約設計用於作為路由邏輯的一部分執行批次呼叫，但不應是用戶直接授權進行代幣轉帳的支出方 (spender)。

由於 ERC-20 餘額檢查僅針對支出方位址，任何結合用戶授權與無限制任意呼叫能力的合約都會產生危險的授權陷阱：一旦被授權，如果任何人都能控制其發出的呼叫，該合約就會變成一個通用的代幣提取媒介。

漏洞分析

此事件並非由智能合約漏洞引起。損失是由兩個條件共同作用造成的：誤將授權目標設定為 SquidMulticall 而非 Router，以及 run() 函數接受來自任何調用者的任意目標和 calldata 的無權限設計。

SquidMulticall 旨在作為 Router 流程的下游步驟執行批次呼叫，其中的輸入由受信任的路由邏輯構建。在預期用途下，這種無權限設計並無風險。但誤授權完全改變了情況：一個 MEV 機器人偵測到了即時的授權額度，並以設計好的 calldata 調用 run()，執行 transferFrom(victim, attacker, amount)，從而在沒有受害者進一步操作的情況下，跨鏈抽乾了受權的代幣。

攻擊分析

受害者在 BNB Chain, Arbitrum, Optimism, Avalanche 以及 Base 鏈上均受到影響。以下分析基於攻擊交易 0x81d0c4...9b1301e9。

• 步驟 1：受害者 (0xacc0...f40e98) 錯誤地授權了 SquidMulticall 而非原本預期的 Squid Router。

• 步驟 2：MEV 機器人發現了此授權，並以精心構造的 calldata 調用了 SquidMulticall.run()。

• 步驟 3：通過該任意呼叫，SquidMulticall 執行了 transferFrom(victim, attacker, amount)，將已授權的資產從受害者的錢包中轉走。

結論

此事件說明了當無權限的任意呼叫合約與面向用戶的授權流程並存時的風險。直接原因是錯誤操作導致的誤授權，而由於 SquidMulticall 接受不設限的呼叫者、任意目標和任意 calldata，任何誤給予它的授權都可輕易被武器化並完全利用。使用執行助手合約的協議應考慮增加調用者限制或約束此類函數允許的呼叫目標，從而防止誤操作帶來的嚴重後果。

XBIT 事件

2026 年 4 月 11 日，BNB Chain 上的 XBIT 代幣遭到攻擊，損失約 $53K。根本原因是 XBITVault 中存在一個失敗時開啟 (fail-open) 的存取控制缺陷：transfer() 函數的授權檢查是有條件的——僅在 xbitContract 非零時強制執行 msg.sender == xbitContract，否則靜默通過。由於從未調用過 bindXBIT() 來初始化合約，該缺陷始終暴露，導致任何呼叫者都可以移動任何位址的 XBIT 餘額，包括 XBIT/USDT PancakeSwap 交易對中的餘額。攻擊者利用這一點抽乾了交易對中的 XBIT，然後反覆將極少量的 XBIT 賣回資金池，換取不成比例的大量 USDT。

背景

XBITVault 並非被動的國庫合約，它是 XBIT 代幣系統的餘額和授權後端，暴露了如 transfer()、approve() 和 mintForXBIT() 等代幣相關功能。按預期設計，所有者必須先調用 bindXBIT() 來設置 xbitContract、pancakePair、pairContract 和 xbitDecimals 以初始化金庫。初始化後，敏感的狀態更改函數理論上只能由已綁定的 XBIT 合約調用。換句話說，金庫的安全模型取決於在公開使用前是否成功初始化。

漏洞分析

核心缺陷在於脆弱的 XBITVault 合約 (0xc879...42391a) 中，其存取控制是有條件的。transfer() 函數僅在 xbitContract != address(0) 時檢查 msg.sender == xbitContract。這意味著當 xbitContract 未設置時，該函數不會回滾，轉而變成任何人都可以公開調用的函數。由於餘額存儲在 _balances 中，任何外部呼叫者都可以將 XBIT 從任何位址轉移到任何其他位址，只要來源位址有足夠餘額即可。

預期的初始化路徑是 bindXBIT()，由於從未被調用，金庫一直處於未初始化且「失敗時開啟」的狀態。這實際上變成了一個任意餘額轉移的原語。

攻擊分析

以下分析基於攻擊交易 0xbc877f...4df1b694。

• 步驟 1：通過不受限制的 transfer() 函數，攻擊者將 1,526,216.569 XBIT 從 XBIT/USDT 交易對中移出，而未提供任何相應的 USDT。

• 步驟 2：攻擊者調用 sync() 將交易對的 XBIT 儲備崩潰至僅剩 1-2 個單位。

• 步驟 3：在交易對幾乎沒有 XBIT 流動性後，攻擊者反覆出售 XBIT，從交易對中榨取了約 53,112 USDT。

結論

該事件是由於依賴初始化的存取控制檢查失敗所導致。只要 xbitContract 未設置，transfer() 就是不受限制的；且由於 bindXBIT() 從未被調用，金庫永久暴露了一個公開的、任意餘額轉帳的原語。關鍵權限函數應在初始化完成前默認回滾，部署時的綁定步驟應設定為鏈上強制執行的先決條件，而非操作預設事項。

關於 BlockSec

BlockSec 是一家全棧區塊鏈安全與加密合規服務提供商。我們建立的產品與服務旨在協助客戶執行代碼審計（涵蓋智能合約、區塊鏈底層與錢包）、即時攔截攻擊、分析安全事件、追蹤非法資金，並滿足協議與平台全生命週期中的 AML/CFT 合規職責。

BlockSec 已在多場頂級會議上發表了多篇區塊鏈安全研究論文，報告了多個 DeFi 應用的零日攻擊，成功攔截多次駭客攻擊並挽回超過 2,000 萬美元的損失，累積保障數十億美元的加密貨幣資產。

• 官方網站: https://blocksec.com/

• 官方 Twitter 帳號: https://twitter.com/BlockSecTeam

• 🔗 BlockSec 審計服務 : 提交請求

• 🔗 Phalcon Security APP: 預約演示

• 🔗 Phalcon 合規服務