不活跃的合约，并不等于安全的合约

简介

核心要点：

• 过去一周，BlockSec识别到5起值得关注的攻击事件，涉及BNB Chain、Ethereum、Base、Arbitrum和Cosmos，总估计损失约1600万美元。

• 三起事件涉及签名密钥泄露或链下基础设施被攻破（Stake DAO、Gravity Bridge、Alephium），另外两起则利用了合约层面的缺陷：DxSale代币锁仓合约的状态更新缺失，以及SquidRouterModule对Axelar Bridge集成的输入验证不当。

• DxSale事件表明，长期未维护的合约并不会因为"一直没出事"就安全；未审计的遗留代码可能在部署数年后仍被利用，尤其是当特权密钥遭到泄露时。

过去一周（2026/05/27 - 2026/05/30），BlockSec在多个区块链生态系统中识别到多起攻击事件。下表列出了5起值得关注的事件，总估计损失约1600万美元。

补充说明：

• Stake DAO事件中，攻击者通过泄露的deployer私钥重新配置了Arbitrum上vsdCRV合约的LayerZero v2 OFT peer，铸造了5.4万亿枚vsdCRV。由于DEX流动性有限，仅兑现约$91K后池子便已耗尽。

• Alephium事件中，除了从桥托管资产中直接盗取约$300K（Ethereum上的USDT、USDC、WETH、WBTC以及BNB Chain上的USDT、WBNB）外，攻击者还在Ethereum上铸造了1370万枚无背书的wALPH。桥已被关停，攻击者无法通过Alephium桥赎回或转移这些代币。

以下两起事件被选取进行深入分析：

• **SquidRouterModule：**与CrossCurveFi漏洞如出一辙，再次复现了同一类集成错误：在缺乏深入理解和严格安全审查的情况下复用跨链逻辑，会将继承来的复杂性转化为继承来的风险。

• **DxSale：**其跨越数天的攻击时间线说明，长期未被利用的遗留合约并不等于安全。协议必须持续监控链上行为，最小化特权访问，不能把"多年无事故"当作安全证明。

本周看点：DxSale

在本事件中，一个存在多年的未修补锁仓合约与被泄露的deployer密钥相结合，揭示了一个反复出现的模式：将部署时的代码视为永久安全、不进行持续审计或权限轮换的协议，承担着随时可能被武器化的隐性风险。

2026年5月29日，BNB Chain上的代币发行与流动性锁仓平台DxSale遭到攻击，损失约730万美元。代币提取函数存在三个缺失的状态更新，使得任何持有有效锁仓仓位的用户都可以通过反复提取来耗尽整个共享池，无需owner权限。DxSale deployer密钥通过EIP-7702委托方式被泄露并非攻击的前提条件，但放大了攻击者的效率：通过手续费操纵和阻止其他用户创建新锁仓，加速了资金耗尽。

背景

DxSale是BNB Chain上的代币发行与流动性锁仓平台。其DxLock组件允许项目方将LP代币锁入有时间限制的保险库，为投资者提供流动性不会被撤走的保障。

核心锁仓机制如下：用户将代币存入锁仓合约，创建一条以调用者地址和token ID组合为索引的锁仓记录。每条记录存储锁仓是否存在、代币是否处于锁定状态、锁定数量、解锁时间戳和代币地址。锁定期到期后，用户调用unlockToken(tokenId)提取代币。

由于锁仓合约以共享余额的方式同时为多个用户持有代币，个人配额必须通过独立的锁仓记录准确追踪。整个资金池的安全取决于每次提取是否正确验证并更新调用者自身的记录。

漏洞分析

漏洞合约（0xeb3a…e449）的unlockToken函数存在三个叠加缺陷，每个都是缺失的状态更新或校验：

• **缺少锁定期强制校验。**锁定期仅由if语句守护，而非require。在解锁时间戳之前调用时，函数仅跳过清除锁定标志，而非回退交易。这意味着代币可以在任何时间被提取，无视锁定期。

• 锁定金额从未清零。 向调用者转移代币后，函数未将field2（锁定金额）清零。每次后续调用都读取相同的原始值并提取相同数量，形成无限提取循环。

• **共享余额校验而非个人配额校验。**balanceOf(this)调用校验的是合约的总代币余额，而非调用者的个人配额。持有小额锁仓仓位的调用者可以在合约仍有足够总余额时耗尽整个共享池。

三个缺失的状态更新共同消除了函数的所有退出条件：调用永远不会提前回退，提取金额永远不会减少，余额校验永远不会阻断，直到合约被完全清空。该漏洞可被任何创建了锁仓仓位的用户利用，无需owner权限。

攻击分析

DxSale的deployer账户（0x47bacf93）通过EIP-7702委托运作，自2026-04-15起就表现出异常活动，包括批量所有权转移、手续费变更和LP解锁操作。2026-05-26，deployer将受害锁仓合约（0xeb3a…e449）的所有权转移给攻击者合约（0xc457…fa69）。两天后，攻击者执行了五步操作完成资金耗尽。

以下分析基于一笔代表性交易0x437b26…c1b303。

**Step 1：**攻击者在PancakeSwap上将BNB兑换为BNBC代币并提供流动性，创建新的Cake-LP (BNBC/WBNB)交易对，获得约0.323枚LP代币。

**Step 2：**利用此前通过所有权转移获得的owner权限，攻击者调用changeFees(1)将锁仓创建手续费设为1 wei，随后调用createLocker将约0.323枚LP代币存入新的锁仓仓位（tokenId=131）。紧接着，攻击者调用changeFees(10^36)将手续费提升至天文数字，阻止其他用户创建新锁仓。

**Step 3：**攻击者调用exploit函数（0x11b432b4），在单笔交易中编排反复调用unlockToken。通过多笔交易，攻击者系统性地耗尽锁仓合约：0x437b26…c1b303通过tokenId=131提取了161.4枚LP代币，0x82f541…a9fa73和0x5dd61f…4298aa提取了其他锁仓仓位，0xac8f5e…d36df9通过tokenId=319在478次调用中提取了260.3枚LP代币。

**Step 4：**攻击者在PancakeSwap上调用removeLiquidity，将提取的LP代币拆分为底层代币（BNBC和WBNB）。

**Step 5：**攻击者通过PancakeSwap将底层代币兑换为WBNB和BUSD，并将收益转至外部地址。BSCScan记录显示该攻击者合约在4天内（2026-05-28至05-31）产生了123,447笔交易。

结论

本事件的根本原因是unlockToken中三个缺失的状态更新，每个都有直接的修复方式：使用require而非if强制执行锁定期，每次提取后将锁定金额清零，校验调用者的个人配额而非合约总余额。仅凭这三个缺陷即足以构成攻击条件：任何创建了锁仓仓位的用户都可以通过反复调用来耗尽整个共享池，无需owner权限。

DxSale deployer通过EIP-7702委托方式被泄露并非攻击的前提条件，但放大了攻击者的效率。通过转移所有权和操纵手续费，攻击者创建了近零成本的锁仓仓位，并阻止合法用户创建竞争性锁仓。在运营层面，协议必须持续审计遗留合约（尤其是那些持有用户资金的合约），并避免将管理功能的控制权交给单一密钥。多年无事故的运行记录不能替代未审计代码的安全验证。

本周其它事件

SquidRouterModule

2026年5月27日，一个名为SquidRouterModule的未知合约在Ethereum上因输入验证不当遭到攻击，损失约320万美元。根本原因是对Axelar Bridge集成的误用，与此前的CrossCurveFi攻击模式类似。合约未通过Axelar Gateway正确验证跨链消息，使得攻击者可以伪造payload，将受害者的代币授权并swap进预先构建的恶意池。另一个攻击者地址（负责部署假代币和注入流动性）随后撤出流动性，提取真实资产获利。本次攻击影响了86个Safe钱包。尽管名称相似，SquidRouterModule并非由Squid协议团队构建、部署或运营。

背景

该合约是一个为Safe钱包设计的跨链兑换服务模块，基于Axelar跨链协议构建。合约提供expressExecuteWithToken函数，支持在跨链消息确认前提前执行交易。用户使用前需在Safe钱包上预授权该合约的APPROVE和SWAP权限。当expressExecuteWithToken被调用时，合约解码payload中的操作指令，并调用Safe钱包的execTransactionFromModule执行代币授权和兑换操作。

漏洞分析

漏洞合约（0x1f1d…23ca）的_executeWithToken函数仅检查srcAddress是否等于squidRouter常量。然而srcAddress是调用者可控的参数，而squidRouter是任何人都可从合约中读取的不可变字符串。攻击者可以轻松绕过此检查，用任意payload内容执行_processPayload函数。

图：漏洞合约的 _executeWithToken 仅比较调用者可控的 srcAddress

作为对比，合法Squid Router的executeWithToken函数会调用gateway.validateContractCallAndMint()，若Axelar验证者网络未确认交易则以NotApprovedByGateway()回退。

图：合法 Squid Router 通过 gateway 验证跨链消息

漏洞合约未在expressExecuteWithToken路径上强制执行任何此类gateway授权。结合Safe钱包用户预授权给该模块的APPROVE和SWAP权限，伪造的payload可以直接操作受害者的资金。

攻击分析

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

攻击前，另一个攻击者地址部署了假代币（0xe6Ff…3512），创建了多个Uniswap V3池，分别将假代币与不同的有价值代币（如USDC、ENA、USDT）配对，并注入假代币流动性。

**Step 1：**攻击者伪造恶意calldata，调用漏洞合约的expressExecuteWithToken函数，使用已知的squidRouter地址作为sourceAddress绕过验证检查。通过受害者预授权给该模块的APPROVE和SWAP权限，伪造的payload强制将受害者Safe钱包的代币授权给Uniswap池。

**Step 2：**利用这些强制授权，payload将受害者的代币通过对应的恶意池兑换为无价值的假代币。

攻击者通过多笔交易重复相同方法，共攻击了86个已授权漏洞合约的Safe钱包。负责部署假代币和注入流动性的另一个攻击者地址随后撤出池中流动性，提取真实资产，最终获利约320万美元。

结论

本事件的根本原因是跨链消息处理路径中的输入验证不当。唯一的安全检查依赖调用者可控的参数与公开可读的常量进行比较，未提供实质性保护。结合Safe钱包用户预授权的APPROVE和SWAP权限，攻击者可以伪造跨链消息并窃取用户资金。

本事件与CrossCurveFi漏洞具有类似模式：两者都涉及未能正确验证传入跨链消息的Axelar Bridge集成。集成跨链消息基础设施时，目标合约必须通过桥的授权机制独立验证消息真实性。跳过这一验证而依赖攻击者可控的输入，会将集成点变为开放的攻击面。