損失 1590 萬美元：Trusted Volumes、Wasabi 及更多安全事件

在過去的兩週內（2026/04/27 - 2026/05/10），BlockSec 在多個區塊鏈生態系統中識別出多起攻擊事件。下表列出了 11 個值得注意的事件，總預計損失約為 1,590 萬美元。

日期	事件	類型	預計損失
2026/04/27	未知合約事件	存取控制問題	~$708K
2026/04/27	ZetaChain 事件	存取控制問題	~$334K
2026/04/28	JetonRouter 事件	業務邏輯缺陷	~$229K
2026/04/28	QNT 事件	存取控制問題	~$125K
2026/04/28	JUDAO Token 事件	存取控制問題	~$228K
2026/04/29	未知合約事件	存取控制問題	~$983K
2026/04/29	Ycdeal3 事件	存取控制問題	~$398K
2026/04/29	Aftermath Finance 事件	業務邏輯缺陷	~$1.14M
2026/04/30	Wasabi Protocol 事件	金鑰洩漏	~$5.7M
2026/05/07	Trusted Volumes 事件	輸入驗證不足	~$5.87M
2026/05/10	Renegade.fi Darkpool Proxy	存取控制問題	~$220K

基於攻擊的新穎性、財務影響及安全性意義，我們選出三個事件進行深度分析：

Aftermath Finance：針對永續 DEX 的實際攻擊，費用驗證中細微的帶符號/無符號語義不匹配導致協議資金被完全耗盡。
Trusted Volumes：重大的財務影響（約 587 萬美元），清楚地展示了 RFQ 結算邏輯中的授權不匹配問題。
Wasabi Protocol：從基礎設施到合約控制權的妥協，這類攻擊日益普遍，但在審計範圍中卻常被忽略。

本週焦點：Aftermath Finance

此事件之所以被強調，是因為帶符號/無符號語義不匹配是一種超越單一協議的細微漏洞類別。任何使用帶符號定點數庫來驗證無符號費用或價格數值的 DeFi 協議都容易受到相同的攻擊模式影響，這使得該 exploit 對開發者和審計人員都具有廣泛的指導意義。

2026 年 4 月 29 日，Sui 鏈上的鏈上永續期貨交易所 Aftermath Perpetuals 遭到攻擊，損失約 114 萬 USDC [1]。根本原因是協議在建構者費用（builder-fee）驗證中存在帶符號/無符號語義不匹配：費用比較函數對無符號數值執行了帶符號算術運算，允許攻擊者提交一個在帶符號解釋下顯示為負數的費用值。在結算過程中，負費用被轉換為正抵押品信用，使攻擊者能夠從協議金庫中提取誇大後的資金。

背景

Aftermath Perpetuals 是 Sui 鏈上的鏈上永續期貨交易所 [2]。該協議允許外部整合者透過建立前端介面來賺取交易費用。每個整合者設定一個由使用其介面的交易者支付的費率（taker_fee）[3]。為了安全起見，交易者可以透過配置預設費率上限（maxTakerFee）來批准整合者，從而限制整合者可以收取的費用金額。

當執行市價訂單時，協議首先將 taker_fee 與 maxTakerFee 進行比較，以確保費用保持在交易者批准的範圍內，然後從交易者的抵押品中扣除計算出的費用，並將其計入整合者的記錄中。

該協議的算術運算基於帶符號定點數庫（ifixed），該庫將數值表示為 u256 整數，但在比較和算術運算時採用二補數（two's-complement）語義進行解釋。

漏洞分析

存在問題的合約包括介面模組 (0x9e2080...25d136) 和結算中心模組 (0x21d001...7c5068)。

漏洞位於 calculate_taker_fees() 函數中，該函數使用 ifixed::less_than_eq() 來比較整合者的 taker_fee 與交易者的 maxTakerFee：

assert!(
    ifixed::less_than_eq(
        v5.taker_fee,
        account::get_integrator_max_taker_fee(
            account::get_integrator_config(arg1, v5.integrator_address)
        )
    ),
    errors::invalid_integrator_taker_fee()
);

taker_fee 和 maxTakerFee 在語義上都是非負費率。然而，ifixed::less_than_eq() 在 u256 上執行帶符號比較。當 maxTakerFee 設定為 0 時，諸如 2^256 - 10^16 的數值在帶符號語義下被解釋為 -10^16。由於 -10^16 <= 0 成立，檢查通過。

由於 create_integrator_info() 是公開可呼叫的，且未對提供的 taker_fee 強制執行任何權限或費用範圍驗證，攻擊路徑進一步暴露：

public fun create_integrator_info(arg0: address, arg1: u256): Option<IntegratorInfo> {
    let v0 = IntegratorInfo {
        integrator_address : arg0,
        taker_fee          : arg1,
    };
    option::some<IntegratorInfo>(v0)
}

負費用不僅被接受，在結算過程中還被轉化為正向的抵押品信用。在結算路徑中，抵押品更新為 collateral += pnl - taker_fee - builder_fee。當 builder_fee 為負數時，減去它等於加上一個數值：

position::add_to_collateral_usd(
    arg0,
    ifixed::sub(v6, ifixed::add(v7, v8)),
    arg2
);

費用驗證和結算算術都沒有強制要求費用數值必須是非負數，因此這兩個缺失的檢查疊加在一起：帶符號比較允許負值進入，而帶符號算術將其轉換為抵押品信用。

攻擊分析

以下分析基於交易 4pGQdf...wVD8。

第 1 步：攻擊者將 100e6 USDC 分拆到兩個新的永續帳戶 1227 和 1228 中。這創建了隔離的上下文，以便攻擊者能同時扮演做市商（帳戶 1227）和吃單者（帳戶 1228）。
第 2 步：攻擊者將 100e6 USDC 作為抵押品存入帳戶 1227 並開設了一個市場倉位，為即將到來的吃單訂單建立對手方。
第 3 步：攻擊者創建了一個整合者金庫，然後為帳戶 1228 添加了一個 maxTakerFee = 0 的配置。將上限設為零至關重要：它使得帶符號比較 taker_fee <= 0 接受任何在二補數下顯示為負的數值。
第 4 步：攻擊者從帳戶 1227 發起會話並掛出一個 order_size = 100e6 的限價單，提供帳戶 1228 將要針對其進行交易的流動性。
第 5 步：攻擊者以 taker_fee = 2^256 - 100e6 呼叫 create_integrator_info()，該數值在帶符號 ifixed 語義下代表 -100e6。由於該函數是公開的且不執行任何驗證，呼叫成功。
第 6 步：攻擊者使用惡意整合者資訊從帳戶 1228 執行市價訂單。帶符號費用比較通過（-100e6 <= 0），並且在結算過程中負費用從抵押品中被減去，實際上為帳戶 1228 增加了 100e6 的免費抵押品。
第 7 步：攻擊者將帳戶 1228 中膨脹的抵押品解除並提取，獲利 79,610 USDC。攻擊者在多筆交易中重複此模式，總共累積約 114 萬美元。

結論

此事件是由 Aftermath Perpetuals 的建構者費用驗證中存在的帶符號/無符號語義不匹配所引起。核心問題是費用比較函數（ifixed::less_than_eq）在帶符號語義下解釋了無符號費用值。當與執行任何範圍驗證的公開可呼叫費用設定函數結合使用時，攻擊者可以注入一個通過帶符號比較顯示為「負數」的數值，該數值隨後在結算中被轉換為正抵押品。

值得注意的廣泛模式是：任何使用帶符號定點數庫來驗證本質上非負數值（費用、價格、金額）的協議都容易受到相同類型的攻擊。緩解措施應包括：(1) 在進行任何比較前強制確保費用值為非負數（assert!(taker_fee >= 0)），(2) 將 create_integrator_info() 限制為僅授權呼叫者可存取，以及 (3) 對語義上為無符號的數值使用無符號比較函數。

參考資料

本期更多事件

Trusted Volumes

2026 年 5 月 7 日，以太坊上的自定義 RFQ (Request-For-Quote) 代理合約遭到攻擊，從做市商 TrustedVolumes 處抽乾了約 587 萬美元。根本原因是 RFQ 實現合約的訂單填充函數存在授權不匹配：簽名者權限查詢和代幣轉移操作參考了訂單的不同欄位，導致授權檢查在一個位址上通過，而資金卻從另一個位址被扣除。攻擊者抽走了約 1,291 WETH、20.6 萬 USDT、16.94 WBTC 和 127 萬 USDC。

背景

TrustedVolumes 作為部署在以太坊上的 RFQ 協議的做市商營運。做市商持續離線產生簽名的報價；吃單者（通常是交易者或聚合路由合約）在鏈上提交選定的報價，協議合約驗證簽名並透過 transferFrom 移動做市商和吃單者之間的代幣來原子化結算交易。該協議採用無金庫設計：它不託管任何資金。每個做市商預先授予協議合約其打算報價的每種代幣的 ERC-20 額度，協議在填充時直接從做市商的錢包中提取代幣。

為了允許做市商將簽名操作委託給熱錢包，協議合約維護了一個每個做市商的簽名者註冊表。做市商可以呼叫 registerAllowedOrderSigner(signer, allowed) 來將熱錢包設為白名單，任何後續由該簽名者簽署的訂單都會被視為由做市商親自簽署一樣。

漏洞分析

RFQ 代理合約部署在 0xeEeEEe...051756，實現合約位於 0x88eb28...2760d8。

RFQ 實現合約中的訂單填充函數 0x4112e1c2() 透過 ecrecover() 恢復簽名者，並檢查 allowedOrderSigner 對應表以決定是否接受該簽名。此檢查的查找鍵是 varg4，即訂單的吃單方位址。然而，後續扣除資金的 transferFrom 使用的是 varg5，即訂單的做市商欄位。由於 varg4 和 varg5 是訂單結構體中相互獨立的欄位，授權檢查和資金流動操作引用了不同的主體。沒有任何檢查強制要求授權的簽名者網域與實際扣除代幣的位址相符。

registerAllowedOrderSigner 函數將白名單寫入在 msg.sender 下作為外部鍵，而填充路徑則在 varg4 下讀取作為外部鍵。只要 varg4 的呼叫者曾透過 registerAllowedOrderSigner 進行過註冊，授權檢查就會通過，無論 varg5 出現的是哪位第三方做市商位址。

攻擊分析

以下分析基於交易 0xc5c61b...990513。

第 1 步：攻擊者部署了一個攻擊合約，並透過它呼叫 registerAllowedOrderSigner，將攻擊者的 EOA 註冊到允許簽名者的白名單中。這確保了由攻擊者簽署的訂單能通過協議的簽名者授權檢查。

第 2 步：攻擊合約從攻擊者 EOA 中拉取了 4 wei 的 USDC 並向 RFQ 協議授權了 4 wei，讓攻擊合約具備了作為吃單方所需的最少資產。
第 3 步：攻擊者偽造了四筆訂單，每筆訂單均由攻擊者 EOA 簽署，並將 TrustedVolumes 命名為做市商。因為簽名者檢查查找的是 varg4（攻擊者的合約），而 transferFrom 扣除的是 varg5（TrustedVolumes），每一筆訂單都從 TrustedVolumes 抽走了資金。這四筆訂單分別用 1 wei 的 USDC 換取了 1,291 WETH、206,282 USDT、16.939 WBTC 和 1,268,771 USDC，總利潤約為 587 萬美元。

結論

核心缺陷是訂單填充函數中的授權不匹配：用於簽名者權限檢查的位址與實際支付的位址不同。具體來說，registerAllowedOrderSigner 在 msg.sender 下寫入白名單，填充路徑在吃單字段（varg4）下讀取，而 transferFrom 從做市商字段（varg5）扣款。由於這三個操作引用了不同的主體，任何註冊了自己的簽名者的攻擊者都可以偽造訂單來抽走協力廠商做市商的資金。控制資產流動的授權檢查必須以實際支付的位址為關鍵字，且寫入路徑和讀取路徑必須使用相同的位址關鍵字。

Wasabi Protocol

2026 年 4 月 30 日，部署在多個 EVM 鏈上的期權和永續期貨協議 Wasabi Protocol 遭遇安全事件，導致約 570 萬美元的損失（480 萬美元為用戶資金，90 萬美元來自 Wasabi 國庫） [1][2]。攻擊源於基礎設施妥協：公共伺服器上暴露的分析端點洩漏了憑證，最終導致控制協議 EVM 智慧合約的私鑰被竊。利用這些金鑰，攻擊者從 Wasabi 在以太坊、Base、Blast 和 Berachain 上的多個金庫中執行了未經授權的提款。

背景

Wasabi Protocol 在 EVM 鏈（以太坊、Base、Blast、Berachain）和 Solana 上均有部署。此次事件僅限於協議的 EVM 端；Solana 部署和 Prop AMM 未受影響。

Wasabi 的 EVM 合約（WasabiLongPool、WasabiShortPool、WasabiVault）由特權金鑰管理。該協議還運作包括基於 Spring Boot 的分析和監控服務在內的離線基礎設施。

攻擊分析

此事件遵循了「基礎設施到合約控制」的妥協鏈條：

第 1 步：攻擊者發現面向公眾的 Wasabi 伺服器上安裝了 Spring Boot Actuator。Actuator 的堆積轉儲（heap dumps）通常受密碼保護，但該伺服器使用了另一種與標準密碼保護機制不相容的 Spring 框架變體，導致堆積轉儲端點暴露。
第 2 步：攻擊者取回了堆積轉儲，其中包含一個獨立內部伺服器的憑證。
第 3 步：利用洩漏的憑證，攻擊者轉移到內部伺服器，並獲取了控制 Wasabi 的 EVM 智慧合約的私鑰。
第 4 步：掌握特權金鑰後，攻擊者針對 Ethereum、Base、Blast 和 Berachain 上的 WasabiLongPool、WasabiShortPool 和 WasabiVault 合約執行了未經授權的提款流程，總共抽走了約 570 萬美元。

結論

此事件表明，智慧合約安全性並不止於代碼層面。該 exploit 不需要任何鏈上漏洞；攻擊者完全透過基礎設施暴露獲得了控制權。關鍵教訓是：(1) 調試和分析介面（堆積轉儲、分析端點、日誌匯出程式）絕不能在公共基礎設施上公開存取，(2) 生產系統的憑證必須與分析和監控環境嚴格區隔，(3) 智慧合約管理金鑰應受到深度防禦控制的保護，包括多簽託管、硬體簽名、角色分離、即時監控和緊急暫停程序。