简介

核心要点：

• 过去两周，BlockSec 在 Sui、Ethereum、BNB Chain、Base、Blast 和 Berachain 上监测到 11 起具有代表性的攻击事件，总估计损失约 $15.9M。
• 攻击手法涵盖链上费率校验中的 signed/unsigned 语义混淆（Aftermath Finance）、RFQ 结算逻辑中的授权不匹配（Trusted Volumes），以及通过暴露的 Spring Boot Actuator 端点实现的基础设施到合约控制权渗透（Wasabi Protocol）。
• 这些事件表明关键漏洞已超越传统智能合约缺陷的范畴：算术库中的类型语义错误和基础设施暴露都可能独立导致数百万美元的损失。

过去两周（2026/04/27 – 2026/05/10），BlockSec 监测到多起区块链安全事件。下表列出 11 起具有代表性的攻击事件，总估计损失约 $15.9M。

事件概览

其中三起事件因攻击手法新颖、损失金额大或安全启示价值高，被选出进行详细分析：

• Aftermath Finance：永续 DEX 上罕见的 signed/unsigned 语义混淆漏洞，费率校验中的类型错误导致协议资金被完全耗尽，具有较高教育价值。
• Trusted Volumes：损失金额高达约 $5.87M，清晰展示了 RFQ 结算逻辑中的授权不匹配问题。
• Wasabi Protocol：基础设施到合约控制权的跨层攻击，这类攻击日益常见但在审计范围中覆盖不足。

本周看点：Aftermath Finance

本事件被选为重点分析，因为 signed/unsigned 语义混淆是一个适用范围广泛的漏洞类别。任何使用 signed 定点数库来校验 unsigned 费率或价格的 DeFi 协议都可能存在相同风险，这使得该漏洞对开发者和审计人员都具有重要参考意义。

2026 年 4 月 29 日，Sui 链上的永续合约交易所 Aftermath Perpetuals 遭到攻击，损失约 $1.14M USDC（公告）。根本原因是协议的 builder 费率校验存在 signed/unsigned 语义混淆：费率比较函数对 unsigned 值执行了 signed 运算，攻击者因此可以提交一个在 signed 语义下为负数的费率值。在结算时，这个负费率被转换为正的保证金增加量，攻击者随后提取了虚增的资金。

背景

Aftermath Perpetuals 是 Sui 上的永续合约交易所（协议文档）。协议允许外部集成商（integrator）通过构建前端界面来赚取交易费用，每个集成商可设定费率（taker_fee）向交易者收费（Builder Codes 文档）。作为保护机制，交易者可以为每个集成商配置费率上限（maxTakerFee），限制集成商可收取的最大费率。

执行市价单时，协议先将 taker_fee 与 maxTakerFee 比较以确保费率不超过交易者设定的上限，然后从 taker 的保证金中扣除费用并记入集成商账户。

协议的算术运算基于 signed 定点数库（ifixed），以 u256 整数存储数值，但在比较和运算时采用二进制补码语义。

漏洞分析

漏洞涉及的合约包括 interface 模块（0x9e2080…25d136）和 clearing house 模块（0x21d001…7c5068）。

漏洞位于 calculate_taker_fees() 函数，该函数使用 ifixed::less_than_eq() 将集成商的 taker_fee 与交易者的 maxTakerFee 进行比较。

taker_fee 和 maxTakerFee 在语义上都是非负费率值，但 ifixed::less_than_eq() 对 u256 执行的是 signed 比较。当 maxTakerFee 被设为 0 时，2^256 - 10^16 在 signed 语义下被解释为 -10^16，而 -10^16 <= 0 成立，因此检查通过。

漏洞的利用路径还依赖于 create_integrator_info() 缺少权限控制和费率范围校验。

负费率不仅通过了校验，还在结算阶段被转化为正的保证金增加。结算路径中，保证金的更新逻辑为 collateral += pnl - taker_fee - builder_fee，当 builder_fee 为负值时，减去负数变为加法。

费率校验和结算运算均未要求费率值为非负数，两处缺失叠加：signed 比较放行了负值，signed 运算将其转化为保证金增加。

攻击分析

以下分析基于交易 4pGQdf…wVD8。

• Step 1：攻击者将 100e6 USDC 拆分到两个新的永续账户 1227 和 1228，创建隔离的上下文以便同时扮演 maker（账户 1227）和 taker（账户 1228）。
• Step 2：攻击者向账户 1227 存入 100e6 USDC 作为保证金并开仓，为后续 taker 订单提供对手方。
• Step 3：攻击者创建集成商 vault，并为账户 1228 配置 maxTakerFee = 0。将上限设为零是关键：这使得 signed 比较 taker_fee <= 0 可以接受任何在二进制补码下表现为负数的值。
• Step 4：攻击者从账户 1227 发起 session 并挂出 order_size = 100e6 的限价单，为账户 1228 提供交易流动性。
• Step 5：攻击者调用 create_integrator_info()，传入 taker_fee = 2^256 - 100e6，该值在 signed ifixed 语义下表示 -100e6。由于函数为 public 且无校验，调用成功。
• Step 6：攻击者从账户 1228 使用恶意集成商信息执行市价单。signed 费率比较通过（-100e6 <= 0），结算时负费率被减去，实际效果是向账户 1228 增加了 100e6 的可用保证金。
• Step 7：攻击者从账户 1228 提取虚增的保证金，单次获利 79,610 USDC。攻击者在多笔交易中重复此模式，累计获利约 $1.14M。

图 1：Sui 交易事件显示 FilledTakerOrder 中因负 builder fee 而虚增的保证金

结论

该事件由 Aftermath Perpetuals 的 builder 费率校验中的 signed/unsigned 语义混淆导致。核心问题是费率比较函数（ifixed::less_than_eq）以 signed 语义解释 unsigned 费率值，再加上 create_integrator_info() 缺少权限和范围校验，攻击者可以注入在 signed 比较中表现为负数的值，而该值在结算中被转化为正的保证金增加。

这一模式值得广泛关注：任何使用 signed 定点数库校验本质上为非负值（费率、价格、金额）的协议都面临同类风险。建议的修复措施包括：

• 在比较前强制要求费率值非负（assert!(taker_fee >= 0)）。
• 限制 create_integrator_info() 仅允许授权调用者调用。
• 对语义上为 unsigned 的值使用 unsigned 比较函数。

本周其它事件

Trusted Volumes

2026 年 5 月 7 日，以太坊上一个自定义 RFQ（Request-For-Quote）代理合约遭到攻击，做市商 TrustedVolumes 被盗约 $5.87M。根本原因是 RFQ 实现合约的订单执行函数中存在授权不匹配：签名者权限查找与代币转账操作引用了订单中不同的字段，导致授权检查在一个地址上通过，而资金从另一个地址被扣除。攻击者共盗取约 1,291 WETH、206K USDT、16.94 WBTC 和 1.27M USDC。

背景

TrustedVolumes 是以太坊上 RFQ 协议的做市商。做市商在链下持续生成签名报价；taker（通常是交易者或聚合器路由）将选定的报价提交到链上，协议合约验证签名后通过 transferFrom 原子性地完成 maker 和 taker 之间的代币交换。协议采用无托管设计：从不持有资金。每个 maker 预先向协议合约授权其拟报价代币的 ERC-20 额度，协议在成交时直接从 maker 钱包中拉取代币。

为让 maker 可以将签名操作委托给热钱包，协议合约维护了一个签名者注册表。maker 可以调用 registerAllowedOrderSigner(signer, allowed) 将热钱包加入白名单，之后该热钱包签署的订单将被视为 maker 本人签署。

漏洞分析

RFQ 代理合约部署在 0xeEeEEe…051756，实现合约部署在 0x88eb28…2760d8。

RFQ 实现合约中的订单执行函数 0x4112e1c2() 通过 ecrecover() 恢复签名者后，查询 allowedOrderSigner 映射来决定是否接受签名。查找键为 varg4，即订单中的 taker 地址；然而后续执行 transferFrom 扣款的是 varg5，即订单中的 maker 字段。由于 varg4 和 varg5 是订单结构体中的独立字段，授权检查与资金流转引用了不同的主体。缺少校验确保授权签名者域与实际扣款地址一致。

图 2：订单成交函数中授权查找键与资金流转键不匹配

registerAllowedOrderSigner 函数以 msg.sender 作为外层键写入白名单，而执行路径以 varg4 作为外层键读取。只要 varg4 处的调用者此前通过 registerAllowedOrderSigner 注册过自己，授权检查就会通过，而不论 varg5 处的第三方 maker 地址是谁。

攻击分析

以下分析基于交易 0xc5c61b…990513。

• Step 1：攻击者部署攻击合约，通过该合约调用 registerAllowedOrderSigner，将攻击者 EOA 注册到签名者白名单中，确保攻击者签署的订单能通过协议的签名者授权检查。

图 3：Phalcon 追踪显示攻击者将自身注册为允许的签名者

• Step 2：攻击合约从攻击者 EOA 拉取 4 wei USDC 并向 RFQ 协议授权 4 wei，为攻击合约提供作为 taker 所需的最小对价。
• Step 3：攻击者伪造了四笔订单，每笔均由攻击者 EOA 签名且将 TrustedVolumes 指定为 maker。由于签名者检查查找的是 varg4（攻击者合约），而 transferFrom 扣款的是 varg5（TrustedVolumes），因此每笔订单都从 TrustedVolumes 转移资金。四笔订单分别以 1 wei USDC 换取 1,291 WETH、206,282 USDT、16.939 WBTC 和 1,268,771 USDC，总获利约 $5.87M。

图 4：Phalcon 追踪显示订单成交执行从 TrustedVolumes 抽走代币

结论

核心缺陷是订单执行函数中的授权不匹配：执行权限检查所用的地址与实际付款地址不同。具体而言，registerAllowedOrderSigner 以 msg.sender 写入白名单，执行路径以 taker 字段（varg4）读取，而 transferFrom 从 maker 字段（varg5）扣款。由于三个操作引用了不同的主体，任何注册了自身签名者的攻击者都可以伪造订单来盗取第三方 maker 的资金。控制资产转移的授权检查必须以实际付款方的地址为键，且写入路径和读取路径必须使用同一个键。

Wasabi Protocol

2026 年 4 月 30 日，跨多条 EVM 链部署的期权和永续合约协议 Wasabi Protocol 遭遇安全事件，损失约 4.8M 为用户资金，$900K 为协议金库资金）（Phalcon 告警、Wasabi 官方说明）。攻击源于基础设施层面的入侵：公开服务器上暴露的分析端点泄露了凭证，最终导致控制协议 EVM 智能合约的私钥被窃取。攻击者利用这些私钥在 Ethereum、Base、Blast 和 Berachain 上执行了未授权提款。

背景

Wasabi Protocol 在 EVM 链（Ethereum、Base、Blast、Berachain）和 Solana 上均有部署。本次事件仅影响 EVM 侧；Solana 部署和 Prop AMM 未受影响。

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

攻击分析

该事件的攻击链为"基础设施 → 合约控制权"的逐层渗透：

• Step 1：攻击者发现 Wasabi 的一台公开服务器上安装了 Spring Boot Actuator。Actuator 的 heap dump 端点通常受密码保护，但该服务器使用的 Spring 框架版本与标准密码保护机制不兼容，导致 heap dump 端点处于暴露状态。
• Step 2：攻击者获取了 heap dump，其中包含另一台内部服务器的访问凭证。
• Step 3：攻击者利用泄露的凭证访问内部服务器，获取了控制 Wasabi EVM 智能合约的私钥。
• Step 4：凭借特权密钥，攻击者对 Ethereum、Base、Blast 和 Berachain 上的 WasabiLongPool、WasabiShortPool 和 WasabiVault 合约执行了未授权提款，总计盗取约 $5.7M。

结论

本次事件表明智能合约安全不止于代码层面。攻击者无需利用任何链上漏洞，仅通过基础设施暴露即获得了合约控制权。核心教训：

• 调试和分析类端点（heap dump、profiling、日志导出）不得在公开基础设施上可访问。
• 生产系统凭证必须与分析和监控环境严格隔离。
• 智能合约管理密钥应采用多重防护，包括多签托管、硬件签名、角色分离、实时监控和紧急暂停机制。