在过去一周（2026年2月2日至2月8日），BlockSec 检测并分析了六起攻击事件，估计总损失约为 380万美元。下表总结了这些事件，每个案例的详细分析将在后续子部分中提供。
| 日期 | 事件 | 类型 | 估计损失 |
|---|---|---|---|
| 2026/02/02 | CrossCurve 事件 | 访问控制 | ~$2.8M |
| 2026/02/03 | GYD 事件 | 不当输入验证 | ~$700K |
| 2026/02/05 | SOFI Token 事件 | Token 设计缺陷 | ~$29.6K |
| 2026/02/05 | 未知 Staking 协议事件 | 不当输入验证 | ~$71.6K |
| 2026/02/07 | LZMultiCall 协议事件 | 任意调用 | ~$142K |
| 2026/02/08 | 未知协议事件 | 不当输入验证 | ~$63K |
1. CrossCurve 事件
简要概述
2026年2月2日，CrossCurve 协议遭到攻击，损失约280万美元。根本原因在于 ReceiverAxelar 合约暴露了一个无需权限的 expressExecute() 函数，该函数绕过了标准的 Axelar Gateway 验证流程。接收方仅根据外部提供的数据执行对等地址检查。因此，攻击者构建了一个恶意的跨链调用来触发销毁和解锁机制，导致攻击者未经授权地获得了999,787,453e18个 EYWA 代币。
背景
CrossCurve 是 Eywa.Fi 开发的跨链桥协议，建立在 Axelar 跨链消息框架之上。
在 Axelar 的预期安全模型中，跨链消息由 Axelar Gateway 中继，并在目标链上通过 validateContractCall() 进行显式验证。只有经过 Gateway 加密批准的消息才允许继续执行。
为了降低延迟，Axelar 还提供了一个快速执行机制，允许接收方合约在 Gateway 完成最终验证之前乐观地执行消息。此设计需要严格的访问控制，以确保只有受信任的执行者才能调用快速执行路径；否则，未经验证的跨链消息可能会被过早处理。
漏洞分析
根本原因在于 ReceiverAxelar 暴露了一个无需权限的 expressExecute() 函数，该函数可以直接访问特权的 _execute() 路径，而无需 Axelar Gateway 授权。
在 Axelar 的正确安全模型中，跨链消息必须首先通过基于证明的执行由 Gateway 批准，然后在目标链上通过 validateContractCall() 进行验证，该验证将 (commandId, sourceChain, sourceAddress, contractAddress, payloadHash) 绑定到一次授权执行。
然而，expressExecute() 路径完全跳过了此验证。它仅依赖于使用 sourceChain 和 sourceAddress 的对等检查，而这两者都由攻击者控制，因此不提供任何实际安全性。这使得攻击者能够提供伪造的消息，强制执行 receiveData 分支，并执行最终触发 Eywa CLP Portal 上 unlock() 的任意有效载荷，导致跨链资产被未经授权地释放。
攻击分析
-
步骤 1： 攻击者直接调用
expressExecute()，伪造了sourceChain、sourceAddress和payload。由于expressExecute()绕过了 Gateway 验证并直接进入_execute()，因此唯一剩余的安全措施是进行对等地址白名单检查：require(peers[sourceChain] == sourceAddress.toAddress())。此检查不足够，因为sourceChain和sourceAddress都是外部提供的。通过提供正确的白名单对等地址，攻击者绕过了此检查。 -
步骤 2： 伪造的
payload随后被转发到Receiver.receiveData()分支。resume()函数根据恶意有效载荷执行了跨链操作PortalV2.unlock()，导致资金被未经授权地解锁给攻击者。
结论
此事件的根本原因是 跨链接收方合约中加速执行路径的访问控制不足。通过将 expressExecute() 暴露为无需权限的函数，并仅依赖外部提供的对等信息，CrossCurve 实际上允许攻击者绕过 Axelar Gateway 的安全保障并执行任意跨链有效载荷。
为了减轻未来类似的风险，集成快速或乐观执行机制的跨链协议应：
- 对快速路径执行函数强制执行 严格的调用者身份验证，确保只有受信任的中继者或网关才能调用它们。
- 避免依赖 攻击者控制的元数据（如源链或地址）作为授权的唯一依据。
- 将快速执行视为特权操作，并应用与标准验证执行路径相等的纵深防御检查。
在设计跨链系统时，仔细遵守这些原则至关重要，因为单一的验证绕过可能导致跨多个网络的系统性资产损失。
2. GYD 事件
简要概述
2026年2月3日，GYD Protocol 遭到攻击，损失约70万美元。根本原因在于其 CCIP 接收方信任攻击者控制的消息数据作为执行上下文。该攻击由从 Arbitrum 发送的 CCIP 消息触发，该消息在消息层得到了正确认证，但其解码后的有效载荷后来在 _ccipReceive() 中用于执行任意外部调用。通过将解码后的接收方设置为 GYD 代币合约并提供 approve(attacker, type(uint256).max) 的 calldata，托管合约无意中授予了对其 GYD 余额的无限批准。随后，攻击者通过 transferFrom() 耗尽了资金。
背景
GydL1CCipEscrow 合约是一个建立在 Chainlink CCIP 标准之上的跨链资产托管合约。用户将 GYD 代币锁定在该 L1 上的合约中，然后通过 CCIP 将跨链消息发送到目标链。反之，当跨链消息到达托管合约时，CCIP 会验证其真实性并触发 _ccipReceive()。此函数解析传入的 calldata 以提取 tx.recipient 和 data，根据解析的参数（金额和接收方）执行 GYD 转移或解锁逻辑，并且，如果 data 不为空，则通过 recipient.functionCall(data) 执行任意外部调用。
漏洞分析
核心漏洞在于 GydL1CCipEscrow 在处理来自跨链消息的解码后的 tx.recipient 地址时，并未进行验证。攻击者可以将 tx.recipient 设置为以太坊上的 GYD 代币合约地址，并将 data 构建为 approve(attacker, type(uint256).max)。由于托管合约持有大量锁定的 GYD 代币，这次无限制的外部调用导致托管合约将所有 GYD 代币的全部批准权授予攻击者，然后攻击者可以通过 transferFrom() 耗尽所有资金。
攻击分析
-
步骤 1： 攻击者在 Arbitrum 上发起了一个恶意的 CCIP 消息，将
tx.recipient指定为以太坊上的 GYD 代币合约地址，并将tx.data指定为approve(attacker, type(uint256).max)的编码 calldata。 -
步骤 2： 当消息在以太坊上处理时，
GydL1CCipEscrow合约的_ccipReceive()函数在未验证tx.recipient的情况下，在 GYD 代币合约上执行了批准。攻击者随后调用 GYD 代币上的transferFrom()来耗尽所有托管资金。
结论
此事件的根本原因是 GydL1CCipEscrow 合约在处理跨链消息时未能验证解码后的有效载荷，导致攻击者能够构建恶意的跨链调用。对于跨链桥消息，开发人员应：
- 禁止从托管合约直接调用代币合约：确保跨链消息有效载荷无法调用托管的代币合约。
- 实施执行目标白名单：将
tx.recipient（或tx.target）限制为明确定义的受信任地址集合。
3. SOFI Token 事件
简要概述
2026年2月5日，BNB Chain 上的 SOFI 代币遭到攻击，损失约2.96万美元。
根本原因在于代币重写的 _transfer() 函数中实现了一个有缺陷的销毁机制。通过滥用移除代币直接从 PancakeSwap 流动性池移除并触发后续 sync() 的延迟销毁逻辑，攻击者能够人为地抬高 SOFI 价格。通过反复的转账和交易，攻击者从池中提取了过量的 USDT 流动性，并以盈利的方式偿还了闪电贷。
背景
SOFI 是一个部署在 BNB Chain 上的自定义 ERC-20 代币。与标准的 ERC-20 实现不同，SOFI 代币重写了内部的 _transfer() 函数，以嵌入与卖出操作期间销毁代币相关的附加逻辑。
该代币在 PancakeSwap 式的恒定乘积 AMM 池（SOFI-USDT）中进行交易。在这些池中，代币价格由代币储备的比例决定。对池余额的任何意外更改，尤其是非交易引起的更改，都可能直接操纵价格。
在此设计中，代币合约本身在转账期间与流动性池交互，使得池的储备会计依赖于代币侧的逻辑，而不是纯粹的 AMM 机制。
漏洞分析
漏洞在于 SOFI 的销毁机制与 _transfer() 内的池交互相结合。
当 SOFI 代币转账到流动性池地址时，合约会将此转账解释为卖出，并增加内部累加器变量 waitBurnTokenAmount。然而，累积的金额不会立即销毁。相反，它会在后续转账到池中时从池的余额中销毁，之后会调用池的 sync() 函数。
此设计引入了两个关键问题：
-
直接操纵池余额 直接从池中销毁代币会减少 SOFI 储备，而没有相应的 USDT 流出，违反了 AMM 不变式并人为地提高了 SOFI 价格。
-
延迟且可由攻击者控制的执行 由于销毁仅在 将来的 转账时发生，攻击者可以精确控制销毁和
sync()发生的时间，从而使他们能够利用价格扭曲获利。
结果是，池价格不再反映真实的供需动态，从而实现了可提取的套利。
攻击分析
- 步骤 1： 通过闪电贷借入
USDT。 - 步骤 2： 在
SOFI-USDT池中用USDT兑换SOFI。 - 步骤 3： 将
SOFI转入池中并调用skim()以最小损失增加waitBurnTokenAmount。 - 步骤 4： 再次将
SOFI转入池中以触发销毁 +sync()，提高SOFI价格，然后用SOFI兑换USDT。 - 步骤 5： 重复步骤 4。新累积的
waitBurnTokenAmount仅在下一次转账时销毁，因此需要多次迭代。 - 步骤 6： 从池中耗尽
USDT，然后偿还闪电贷。
结论
此事件最终是由一个不安全的代币侧销毁机制引起的，该机制直接操纵了 AMM 池余额。通过在 _transfer() 中嵌入延迟销毁逻辑并将销毁操作从流动性池本身执行，SOFI 代币打破了恒定乘积 AMM 的基本假设，并实现了确定性的价格操纵。
对于重写 _transfer() 的 ERC-20 代币，开发人员应特别注意避免：
- 直接从流动性池销毁代币
- 引入影响池储备的延迟或有状态机制
- 将代币逻辑与 AMM 内部机制过度耦合
总的来说，代币经济相关的逻辑不应允许任意改变池余额，因为即使是微小的偏差也可能被反复利用来耗尽流动性。
4. 未知 Staking 协议事件（2026年2月5日）
简要概述
2026年2月5日，以太坊上的未知 Staking 协议遭到攻击，损失约7.16万美元。
根本原因在于该协议在提款过程中依赖未经验证的用户输入数据。具体来说，该协议将攻击者控制的 routerCalldata 和 LP 金额转发给 Pendle Router，而未进行验证。通过构建移除该协议全部 LP 头寸的 calldata 并将攻击者设置为接收方，攻击者能够耗尽金库持有的所有资产。
背景
未知 Staking 协议是一个建立在 Pendle Finance 之上的简单收益金库。用户将资产存入金库，金库然后通过 Pendle Router 将这些资产路由以铸造收益型头寸。在内部，存款被转换为 SY，分成 PT 和 YT，然后组合形成 Pendle LP 代币。
协议保管所有 LP 代币，并维护每个用户存入的基础金额的内部会计。当用户提款时，金库通过 Pendle Router 赎回 LP 代币，并将相应的资产返还给用户。
漏洞分析
根本原因是未经验证的输入数据。withdrawWithCalldataMultiToken() 函数接受四个参数：基础代币、基础金额、LP 金额和 routerCalldata。它仅检查用户记录的基础余额是否足够，但不对 LP 金额或 routerCalldata 的内容进行验证。在通过 Pendle Router 移除流动性时，合约完全依赖于嵌入在 routerCalldata 中的参数。因此，攻击者可以提供该协议的全部 LP 余额，并将自己设置为接收方，耗尽金库持有的所有资产。
攻击分析
- 步骤 1： 进行
USDC闪电贷。 - 步骤 2： 向协议存入少量
USDC，协议通过Pendle Router路由资金以添加流动性并铸造 LP。 - 步骤 3： 调用
withdrawWithCalldataMultiToken()，并将routerCalldata构建为将receiver设置为攻击者，将lpAmount设置为协议的全部 LP 余额。 - 步骤 4： 该协议通过
Pendle Router使用攻击者控制的参数移除流动性，并将所有资产发送给攻击者。 - 步骤 5： 将收到的资产兑换回
USDC，偿还闪电贷，并保留剩余部分作为利润。
结论
此事件最终是由于在关键的提款路径中盲目信任攻击者控制的外部输入所致。通过将任意 calldata 和 LP 金额转发给外部路由器而不进行验证，该协议允许用户执行超出其应得份额的提款，导致金库的 Pendle 头寸被完全耗尽。
对于生产金库和收益策略，特别是那些集成复杂外部路由器的，开发人员应：
- 将所有用户提供的输入，包括 calldata，视为不受信任的，并进行严格验证。
- 从内部派生敏感参数（如 LP 金额和接收方），而不是从用户处接受。
- 通过强制内部会计与外部执行结果之间的一致性来应用纵深防御。
否则，即使一次提款调用也可能危及协议持有的所有资产。
5. LZMultiCall 协议事件
简要概述
2026年2月7日，LZMultiCall 事件导致以太坊上损失约14.2万美元。
该事件并非由 LZMultiCall 合约本身的漏洞引起，而是由于用户误用。LZMultiCall 是一个无状态的批量执行合约，不设计用于托管资产或持有 ERC-20 批准。然而，一些用户错误地向该合约授予了代币批准。攻击者随后利用这些悬空的批准，通过调用 execute() 并提供恶意构造的 calldata 来调用 transferFrom()，从而耗尽了受影响用户的代币。
背景
LZMultiCall 是一个通用的批量执行工具合约。其预期用途是允许用户将多个调用捆绑到一个交易中，将用户提供的 calldata 转发给目标合约。
关键在于，LZMultiCall 被设计为无状态且非托管的。它不打算持有资产，用户也永远不应授予它 ERC-20 批准。授予 LZMultiCall 的任何代币批准都违反了其明确的使用假设，并使风险暴露给用户，因为该合约可以代表调用者转发任意调用。
漏洞分析
尽管 LZMultiCall 按设计运行，但一旦用户错误地授予其 ERC-20 批准，其无权限的 execute() 函数就变得可利用。由于该合约将任意 calldata 转发给任何目标，攻击者可以通过编码 transferFrom(victim, attacker, amount) 到代币合约的 calldata 调用 execute()，从而有效地耗尽任何未决的批准。
攻击分析
- 攻击者调用
execute()，并提供针对代币合约的恶意构造的 calldata，使用transferFrom()从已错误地批准了对LZMultiCall批准的用户的账户中转移代币。
结论
此事件最终是由于违反了无状态批量执行合约的明确使用假设。LZMultiCall 从未设计为托管资金或持有 ERC-20 批准。一旦用户错误地授予批准，该合约的无权限执行模型就允许任何调用者通过任意转发调用来耗尽这些批准。
对于与批量执行或多调用类合约交互的用户和集成商：
- 切勿向未明确设计用于托管资产的合约授予 ERC-20 批准。
- 将通用调用转发合约视为不受信任的执行表面。
- 尽可能优先考虑每笔交易的批准或免批准设计（例如
permit）。
即使在协议漏洞不存在的情况下，对合约信任模型的误解也可能导致重大且不可逆的损失。
6. 未知协议事件（2026年2月8日）
简要概述
2026年2月8日，以太坊上的未知协议遭到攻击，损失约6.3万美元。
根本原因在于 Gnosis Safe 模块执行路径中未经验证的攻击者控制的输入数据。一个注册为 SafeModule 的实用合约 (0xF5E4) 暴露了一个闪电贷回调函数，该函数解码了任意用户提供的 userData 并直接调用 GnosisSafe.execTransactionFromModule()。由于模块发起的调用在设计上绕过了签名验证，攻击者能够执行任意 Safe 授权的交易，偿还 Safe 的 Aave V3 债务，并将所有抵押品提取到攻击者控制的地址。
背景
该协议架构围绕一个管理 Aave V3 杠杆头寸的 Gnosis Safe。Gnosis Safe 支持模块化执行模型，其中指定的 SafeModules 被允许代表 Safe 执行交易，而无需所有者签名。此设计旨在支持自动化、集成和高级策略。
在此设置中，合约 0xF5E4 被配置为 Gnosis Safe 的 SafeModule。该合约似乎是一个用于支持基于闪电贷的头寸管理的辅助实用程序。它实现了一个闪电贷回调函数 receiveFlashLoan()，该函数由外部流动性提供者在闪电贷执行期间调用。
由于模块调用绕过了签名验证，模块逻辑的正确性和安全性至关重要：任何缺陷实际上都授予了对 Safe 的不受限制的控制权。
漏洞分析
SafeModule 0xF5E4 暴露了一个闪电贷回调函数 receiveFlashLoan()，该函数解码了外部提供的 userData 并直接使用它来调用 GnosisSafe.execTransactionFromModule()。由于 0xF5E4 被注册为 SafeModule，因此来自它的调用绕过了签名验证。然而，receiveFlashLoan() 未对调用者进行身份验证，也未验证解码的参数（例如目标地址、值、calldata 或操作类型）。因此，攻击者可以提供精心构造的 userData，使该模块通过 Safe 执行任意交易，从而使他们能够偿还 Safe 的 Aave V3 债务，提取所有抵押品，并耗尽头寸以获利。
攻击分析
- 步骤 1： 攻击者通过 Uniswap V4 进行闪电贷，并将资金转入
GnosisSafe。 - 步骤 2： 攻击者调用 Balancer 的
flashLoan()，并提供精心构造的userData，不借入任何实际资产，并将recipient设置为0xF5E4。 - 步骤 3： 在
0xF5E4.receiveFlashLoan()中，合约解码了攻击者提供的userData。由于0xF5E4被注册为 Safe 模块，它绕过了签名检查，并调用execTransactionFromModule()来执行由userData中嵌入的参数决定的任意调用。 - 步骤 4： 利用此能力，攻击者偿还了
GnosisSafe在 Aave V3 上的债务，并提取了所有抵押品，从而实现了利润。
结论
此事件最终是由模块化执行的不安全使用以及未经验证的外部输入引起的。通过将任意、攻击者提供的 userData 转发给 execTransactionFromModule()，SafeModule 0xF5E4 实际上暴露了对 Gnosis Safe 的不受限制的控制。由于 Safe 模块在设计上绕过了签名检查，此漏洞导致 Safe 的 Aave V3 头寸被完全攻破。
对于依赖 Gnosis Safe 模块或类似特权执行框架的系统，开发人员应：
- 将所有外部输入，包括闪电贷
userData，视为不受信任的，并进行严格验证。 - 将模块执行限制在明确定义的动作、目标和选择器集内。
- 避免转发任意 calldata 到特权执行函数的通用“实用”模块。
未能执行这些安全措施可能导致单个辅助合约成为完整的管理后门。
关于 BlockSec
BlockSec 是一个全栈式区块链安全和加密合规提供商。我们构建产品和服务，帮助客户在协议和平台的整个生命周期中执行代码审计（包括智能合约、区块链和钱包）、实时拦截攻击、分析事件、追踪非法资金，并满足 AML/CFT 义务。
BlockSec 已在顶尖会议上发表了多篇区块链安全论文，报告了 DeFi 应用的多个零日攻击，通过阻止多次黑客攻击挽救了超过2000万美元，并保护了数十亿美元的加密货币。
-
🔗 BlockSec 审计服务 : 提交请求
-
🔗 Phalcon 安全应用: 预订演示
