损失1600万美元：DxSale、SquidRouterModule及更多 | BlockSec周报

在过去的一周（2026/05/27 - 2026/05/30）中，BlockSec 监测到多个区块链生态系统中发生了多起攻击事件。下表列出了 5 起重大事件，预估总损失约为 1600 万美元。

*补充说明：

• 在 Stake DAO 事件中，攻击者通过泄露的部署者私钥重新配置了 Arbitrum 上 vsdCRV 合约的 LayerZero v2 OFT 对等方，从而铸造了 5.4 万亿枚 vsdCRV。由于去中心化交易所（DEX）流动性有限，在流动性池耗尽前，攻击者仅套现约 9.1 万美元。
• 在 Alephium 事件中，除了被抽干的约 30 万美元跨链桥托管资产（以太坊上的 USDT、USDC、WETH、WBTC 以及 BNB Chain 上的 USDT、WBNB）外，攻击者还在以太坊上铸造了 1370 万枚无背书的 wALPH。目前该跨链桥已被关闭，阻止了攻击者通过 Alephium 跨链桥赎回或跨回这些代币。

我们选取了两起事件进行深度分析：

• The SquidRouterModule 合约：如同 CrossCurveFi 事件一样，它重复了同一类集成错误。这表明，如果在没有深入理解和严谨安全审查的情况下盲目分叉跨链逻辑，继承而来的复杂性会迅速转化为致命的风险。
• DxSale：其漫长的攻击周期表明，未经利用的旧版合约并不等同于绝对安全；协议必须持续审计休眠的基础设施，最小化特权访问，切勿将多年的平稳运行误认为安全的证明。

本周重点：DxSale

本事件入选周度亮点是因为，一个多年未修补的存管合约与部署者私钥泄露的结合，揭示了一个反复出现的模式：那些认为部署后的代码永久安全、没有持续审计或权限轮换的协议，始终潜藏着随时可能被武器化的风险。

2026 年 5 月 29 日，BNB Chain 上的代币销售和流动性锁定平台 DxSale 遭到攻击 [1]，损失约 730 万美元。代币提取函数中缺少三处关键状态更新，导致任何拥有有效锁定记录的用户都可以反复提取并抽干整个共享资金池，且无需任何所有者权限。虽然利用 EIP-7702 授权劫持 DxSale 部署者私钥并非攻击的前提，但通过操纵费用和阻碍其他用户创建新锁，攻击者极大地提升了实施效率。

背景

DxSale 是 BNB Chain 上的代币销售和流动性锁定平台。其 DxLock 组件允许项目开发者将流动性代币（LP Token）锁在限时金库中，向投资者保证流动性不会被撤走。

其核心锁定机制如下：用户将代币存入存管合约，创建一条以调用者地址和代币 ID 为索引的锁定记录。每条记录存储了锁定是否存在、代币当前是否处于锁定状态、锁定金额、解锁时间戳及代币地址。当锁定期满，用户通过调用 unlockToken(tokenId) 来提取代币。

由于存管合约同时为多名用户持有共享余额，因此必须通过独立的锁定记录准确跟踪每份分配。整个资金池的安全性取决于每次提取操作是否正确验证了调用者自己的记录，并在转账后进行更新。

漏洞分析

该问题合约（0xeb3a...e449）中的 unlockToken 函数存在三处叠加缺陷，每一处都是关键的状态更新或检查缺失：

function unlockToken(uint256 tokenId) public nonPayable {
    require(_increaseLockTime[msg.sender][tokenId].field0_0_0);  // 锁定是否存在
    require(_increaseLockTime[msg.sender][tokenId].field0_1_1);  // 代币是否处于锁定状态
    require(_increaseLockTime[msg.sender][tokenId].field2);       // 金额 > 0

    if (block.timestamp > _increaseLockTime[msg.sender][tokenId].field3) {
        _increaseLockTime[msg.sender][tokenId].field0_1_1 = 0;
    }

    v0, v1 = _increaseLockTime[msg.sender][tokenId].field5_0_19.balanceOf(this);
    require(v1 >= _increaseLockTime[msg.sender][tokenId].field2);
    v2, v3 = _increaseLockTime[msg.sender][tokenId].field5_0_19.transfer(
        msg.sender, _increaseLockTime[msg.sender][tokenId].field2
    );
}

1. 未强制执行锁定期。 锁定期通过 if 语句而非 require 进行判断。当在解锁时间戳之前调用时，函数未能 revert 而是简单地跳过了清除锁定标志位的逻辑。这意味着无论锁定期是否结束，代币均可被随时提取。

2. 锁定金额永不归零。 代币转账给调用者后，函数未将 field2（锁定金额）清零。随后的每次调用都会读取原有的金额并再次进行提取，从而形成无限提现循环。

3. 使用共享余额检查而非个人额度核对。 对 balanceOf(this) 的调用校验的是合约的总余额，而非调用者的个人分配额。只要合约中仍有足够的代币，任何持有少量锁定份额的用户都可以抽干整个共享资金池。

这三处缺失的状态更新移除了函数中所有的退出条件：代码永远不会提前终止，提取金额永远不会减少，余额检查也无法在合约被完全清空前终止调用。该漏洞可被任何创建了锁定的用户利用；核心抽干操作并不需要任何所有者权限。

攻击分析

DxSale 部署者账户（0x47bacf93）利用 EIP-7702 授权，自 2026/04/15 以来表现出异常活动，包括跨多个 DxSale 合约的大规模所有者权限转移、费用变更及 LP 解锁操作。2026/05/26，部署者将受害合约（0xeb3a...e449）的所有权转移至攻击者合约（0xc457...fa69）。两天后，攻击者执行了五步抽水过程。

以下分析基于代表性交易 0x437b26...c1b303。

• 第 1 步：攻击者在 PancakeSwap 上将 BNB 兑换为 BNBC，并通过添加流动性创建新的 Cake-LP (BNBC/WBNB) 对，获得了约 0.323 枚 LP 代币。

• 第 2 步：利用之前获得的所有者权限，攻击者调用 changeFees(1) 将锁定费设为 1 wei，随后调用 createLocker 将约 0.323 枚 LP 代币存入一笔新的锁定资金中（tokenId=131）。随后，攻击者立即将费用改为天文数字，阻止了其他用户创建新锁。

• 第 3 步：攻击者调用攻击函数（0x11b432b4），在单笔交易中编排了多次 unlockToken 调用。通过多次交易，攻击者系统地抽干了金库：0x437b26...c1b303 通过 tokenId=131 抽走了 161.4 枚 LP 代币，0x82f541...a9fa73 和 0x5dd61f...4298aa 抽走了其他锁定份额，0xac8f5e...d36df9 通过 478 次调用经 tokenId=319 抽走了 260.3 枚 LP 代币。

• 第 4 步：攻击者在 PancakeSwap 上调用 removeLiquidity 将抽离出的 LP 代币还原为其基础代币（BNBC 和 WBNB）。

• 第 5 步：攻击者将基础代币通过 PancakeSwap 兑换为 WBNB 和 BUSD 并将收益转移至外部地址。据 BSCScan 记录，该攻击者合约在 4 天内（2026/05/28 至 05/31）共进行了 123,447 笔交易。

总结

该事件的根本原因在于 unlockToken 函数中三处状态更新的缺失。每一处都有直接的修复方法：使用 require 而非 if 来强制执行锁定期，在每次提取后将锁定金额置零，并核对调用者的个人份额而非合约的总余额。这些缺陷足以支撑攻击；任何创建了锁定的用户均可反复调用并抽干整个共享资金池，无需任何特权。

先前利用 EIP-7702 授权劫持 DxSale 部署者的行为并非利用漏洞的先决条件，但却大大提升了攻击效率。通过转移所有权和操纵费用，攻击者不仅创建了几乎零成本的锁定份额，还封锁了合法用户的竞争。在运营层面，协议必须持续审计包括存管合约在内的旧版代码，尤其是涉及用户资金的部分，并避免由单一私钥管理核心权限。多年来未发生安全事件，并不代表未经审计的代码就是安全的。

参考资料

• [1] DxSale 官方公告

本周其它事件

The SquidRouterModule 合约

2026 年 5 月 27 日，一个名为 SquidRouterModule 的未知合约在以太坊上遭到攻击 [1]，原因是输入验证不严，造成约 320 万美元损失。根本原因是 Axelar Bridge 集成的不当使用，与之前的 CrossCurveFi 攻击模式相似 [2]。该合约未对通过 Axelar 网关的跨链消息进行正确校验，导致攻击者能够伪造有效载荷（payload），授权并将受害者的代币兑换到预先构造的恶意池中。随后，另一个部署了假代币并为资金池提供流动性的攻击者地址撤出了真实资产。此攻击影响了 86 个 Safe 钱包。尽管其名称如此，但 SquidRouterModule 并非由 Squid 协议团队构建、部署或运营 [3]。

背景

该合约是为 Safe 钱包设计的跨链交易所服务模块，建立在 Axelar 跨链协议之上。该合约提供了 expressExecuteWithToken 函数，支持在跨链消息确认前进行提前执行。用户在使用该服务前，必须为其 Safe 钱包预授权该合约的 APPROVE 和 SWAP 权限。当调用 expressExecuteWithToken 时，合约会解码有效载荷中的操作指令，并调用 Safe 钱包的 execTransactionFromModule 来执行代币授权和交换操作。

漏洞分析

该易受攻击合约中的 _executeWithToken 函数（0x1f1d...23ca）仅检查了 srcAddress 是否等于 squidRouter 常量。然而，srcAddress 是由调用者提供的参数，而 squidRouter 是任何人都可以从合约中读取的常量字符串。这使得攻击者可以轻而易举地绕过检查，并以任意有效载荷内容执行 _processPayload 函数。

相比之下，合法的 Squid Router 合约在调用 executeWithToken 时会调用 gateway.validateContractCallAndMint()，如果 Axelar 验证者网络尚未确认交易，则会触发 NotApprovedByGateway() 回滚。

该易受攻击的合约在 expressExecuteWithToken 路径上并未强制执行此类网关授权。加之 Safe 钱包用户已向该模块预授权了 APPROVE 和 SWAP 权限，伪造的有效载荷可以直接操作受害者的资金。

攻击分析

以下分析基于交易 0xd29d1c...3bb854。

攻击前，另一个攻击者地址部署了一个假代币（0xe6Ff...3512）并创建了多个 Uniswap V3 资金池，将该假代币与不同的高价值代币（如 USDC、ENA、USDT）配对，并向这些池中注入了假代币流动性。

• 第 1 步：攻击者伪造恶意数据，调用受害合约的 expressExecuteWithToken 函数，利用已知的 squidRouter 地址作为 sourceAddress 绕过校验。通过受害者预授权给该模块的资产操作权限，伪造的有效载荷强迫受害者的 Safe 钱包授权向 Uniswap 池进行代币质押。

• 第 2 步：利用这些强制授权，有效载荷通过相应的恶意资金池将受害者的代币兑换为毫无价值的假代币。

攻击者在多笔交易中重复该方法，共计针对 86 个授权了该合约的 Safe 钱包。随后，此前负责部署假代币及注入流动性的攻击者地址提取了资金池中的流动性，最终非法获利约 320 万美元。

总结

本次事件是由跨链消息处理路径上的输入验证不严造成的。唯一的安全校验仅依赖于与公开可见常量进行比对的、由调用者可控的参数，这完全没有起到实际的保护作用。配合 Safe 钱包用户的预授权权限，攻击者得以伪造跨链消息并窃取资金。

该事件与 CrossCurveFi 事件严重类似 [2]：两者均涉及在 Axelar Bridge 的集成中未能正确识别与验证传入的跨链消息。在集成跨链消息基础设施时，目标合约必须通过跨链桥的授权机制独立校验消息的真实性。跳过这种验证并依赖受攻击者可控的输入，无异于将集成接口直接暴露为空开的攻击面。

参考资料

• [1] Phalcon Alert: SquidRouterModule 攻击通告
• [2] Phalcon Alert: CrossCurveFi 攻击模式详解
• [3] Squid Router 官方说明

关于 BlockSec

BlockSec 是一家全栈式区块链安全和加密资产合规解决方案提供商。我们打造的产品和服务，致力于帮助客户在协议与平台的全生命周期中进行代码审计（涵盖智能合约、区块链底层与钱包）、实时拦截攻击、分析安全事件、追踪非法资金，并满足 AML/CFT（反洗钱/反恐怖融资）法规要求。

BlockSec 已在知名安全会议上发表多篇区块链安全论文，报告了多个 DeFi 应用的零日漏洞，实时拦截并成功挽救了超过 2000 万美元的资产，守护了数十亿加密资产的安全性。

• 官方网站：https://blocksec.com/

• 官方 Twitter 账号：https://twitter.com/BlockSecTeam

• 🔗 BlockSec 审计服务 : 提交审计申请

• 🔗 Phalcon Security 应用：演示预约

• 🔗 Phalcon 合规性服务