损失1590万美元：Trusted Volumes、Wasabi等项目遭攻击

在过去的两周内（2026/04/27 - 2026/05/10），BlockSec 在多个区块链生态系统中识别出多起攻击事件。下表列出了 11 起重大事件，估计总损失约为 1590 万美元。

日期	事件	类型	预计损失
2026/04/27	未知合约事件	访问控制问题	~$70.8万
2026/04/27	ZetaChain 事件	访问控制问题	~$33.4万
2026/04/28	JetonRouter 事件	业务逻辑漏洞	~$22.9万
2026/04/28	QNT 事件	访问控制问题	~$12.5万
2026/04/28	JUDAO Token 事件	访问控制问题	~$22.8万
2026/04/29	未知合约事件	访问控制问题	~$98.3万
2026/04/29	Ycdeal3 事件	访问控制问题	~$39.8万
2026/04/29	Aftermath Finance 事件	业务逻辑漏洞	~$114万
2026/04/30	Wasabi Protocol 事件	密钥泄露	~$570万
2026/05/07	Trusted Volumes 事件	输入验证不足	~$587万
2026/05/10	Renegade.fi Darkpool 代理	访问控制问题	~$22万

基于攻击的新颖性、财务影响及安全隐患，我们选取了以下三起事件进行深入分析：

Aftermath Finance：针对永续合约 DEX 的真实攻击案例。费率验证中微妙的有符号/无符号语义不匹配导致协议资金被完全耗尽。
Trusted Volumes：造成了严重的财务损失（约 587 万美元），清晰地展示了 RFQ 结算逻辑中的授权不匹配问题。
Wasabi Protocol：属于基础设施到合约控制权的泄露，此类攻击日益普遍，但在审计范围中往往被忽视。

每周重点：Aftermath Finance

重点关注此事件的原因在于：有符号/无符号语义不匹配属于一类微妙的漏洞，其影响范围超出了单一协议。任何使用有符号定点数库来验证无符号费率或价格值的 DeFi 协议，都可能受到同样攻击模式的影响。这对于开发者和审计人员都具有广泛的指导意义。

2026 年 4 月 29 日，Sui 链上的永续期货交易所 Aftermath Perpetuals 遭到攻击，损失约 114 万 USDC [1]。根本原因是协议构建者费用（builder-fee）验证中存在有符号/无符号语义不匹配：费率比较函数对无符号值执行了有符号算术运算，允许攻击者提交一个在有符号解释下表现为负数的费率值。在结算过程中，该负费用被转换为正抵押品信用额度，使攻击者能够从协议金库中提取虚增的资金。

背景

Aftermath Perpetuals 是 Sui 链上的一个链上永续期货交易所 [2]。该协议允许外部整合商通过构建前端界面来赚取交易费。每个整合商都会设置一个费用率（taker_fee），向使用其界面的交易者收取 [3]。作为保护措施，交易者可以通过配置预设的最高费率上限（maxTakerFee）来批准整合商，从而限制整合商的收费额度。

执行市价单时，协议首先比较 taker_fee 和 maxTakerFee，以确保费率在交易者批准的范围内，然后从交易者的抵押品中扣除计算出的费用，并将其记入整合商的记录中。

该协议的算术运算基于有符号定点数库（ifixed），它将数值表示为 u256 整数，但在比较和算术运算中按补码语义进行解释。

漏洞分析

有问题的合约包括接口模块 (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 步：攻击者创建了一个整合商金库，并将 maxTakerFee = 0 的配置添加到账户 1228 中。将上限设为 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 万美元。

结论

该 incident 是由 Aftermath Perpetuals 在构建者费用验证中存在有符号/无符号语义不匹配引起的。核心问题在于费用比较函数（ifixed::less_than_eq）将无符号费用值在有符号语义下进行了解释。结合可以公开调用且无范围校验的费用设置函数，攻击者能够注入一个在有符号比较时表现为“负数”的值，并随后在结算过程中被转化为正向抵押品。

值得注意的是更广泛的模式：任何使用有符号定点数库来验证本质上是非负值（费用、价格、金额）的协议，都容易遭受此类漏洞攻击。缓解措施应包括：（1）在进行任何比较前强制要求费用值为非负（assert!(taker_fee >= 0)），（2）限制 create_integrator_info() 仅供授权调用者使用，以及（3）对语义上为无符号的值使用无符号比较函数。

参考资料

本期更多事件

Trusted Volumes

2026 年 5 月 7 日，以太坊上的一个自定义 RFQ（报价请求）代理合约遭到攻击，导致做市商 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 协议，使攻击合约具备了作为吃单方所需的最小额度。
第 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 万美元，Wasabi 金库 90 万美元）[1][2]。此次攻击源于基础设施泄露：公共服务器上暴露的分析端点泄露了凭据，进而导致了控制协议 EVM 智能合约的私钥被盗。攻击者利用这些私钥对以太坊、Base、Blast 和 Berachain 上的多个 Wasabi 金库执行了未经授权的提款。

背景

Wasabi Protocol 在多个 EVM 链（以太坊、Base、Blast、Berachain）以及 Solana 上运行。此次事件仅限该协议的 EVM 端；Solana 部署和 Prop AMM 未受影响。

Wasabi 的 EVM 合约（WasabiLongPool、WasabiShortPool、WasabiVault）是通过特权私钥管理的。该协议还运行包括基于 Spring Boot 构建的分析和监控服务在内的链下基础设施。

攻击分析

该事件遵循了从基础设施到合约控制权泄露的攻击链：

第 1 步：攻击者发现 Spring Boot Actuator 被安装在了一台面向公众的 Wasabi 服务器上。Actuator 堆转储（heap dumps）通常受密码保护，但该服务器使用了与标准密码保护机制不兼容的 Spring 框架变体，导致堆转储端点裸露。
第 2 步：攻击者检索了堆转储，其中包含了其他内部服务器的凭据。
第 3 步：利用泄露的凭据，攻击者转向内部服务器，获取了控制 Wasabi 以太坊智能合约的私钥。
第 4 步：在获得特权私钥后，攻击者在以太坊、Base、Blast 和 Berachain 上对 WasabiLongPool、WasabiShortPool 和 WasabiVault 合约执行了未经授权的提现流程，总共耗尽了约 570 万美元。

结论

此次事件表明智能合约安全不仅限于代码层面。此次攻击无需任何链上漏洞，攻击者完全是通过基础设施暴露获益的。关键教训是：（1）调试和分析表面（堆转储、性能分析端点、日志导出器）绝不能在公共基础设施上访问，（2）生产系统的凭据必须与分析和监控环境严格隔离，（3）智能合约管理私钥应受到深层防御控制的保护，包括多签托管、硬件支撑签名、角色分离、实时监控和紧急暂停程序。