在过去一周（2026/04/06 - 2026/04/12）内，BlockSec 检测并分析了四起攻击事件，总估计损失约为 92.86 万美元。下表总结了这些事件，并将在后续章节提供详细分析。

*Denaria 事件未包含在上周报告中，在此处列出以供完整性。

从本周开始，我们将在每份报告的顶部突出显示一个事件。选择标准不一定基于损失金额 — 它可能因为新颖的协议设计、巧妙的攻击技术或为社区提供的更广泛的经验教训而被选中。

本周重点

Denaria 事件

永续 DEX Denaria 引入了由复杂代码逻辑支持的新型会计机制。然而，在审计后重构引入了四舍五入的不对称性，可能产生细微的边缘情况，即负值，最终导致不安全类型转换，并实现了天文数字的价值提取。

2026 年 4 月 5 日，Denaria 在 Linea 上的永续 DEX 被利用，造成约 16.56 万美元的损失。根本原因在于 getLpLiquidityBalance() 中的两个复合漏洞：为 LP 余额会计进行的审计后重构引入了四舍五入的不对称性，可能产生略微为负的中间值；以及一个不安全的用户定义整数 (int256) 到无符号整数 (uint256) 的类型转换，将该负值静默地包装成接近最大值的无符号整数，而不是回滚。攻击者通过单边 LP 存款和多头交易利用了这一点，然后从金库中提取了人为夸大的盈亏。

背景

Denaria 是 Linea 上一个围绕动态虚拟 AMM 构建的永续 DEX。它将交易和结算分为两个部分。PerpPair 市场负责管理用户头寸和 LP 会计，而 Vault 则持有抵押品并结算已实现的盈亏。

PerpPair 中的 LP 所有权不通过显式代币余额表示。相反，协议通过一个内部会计矩阵重建每个 LP 的状态，该矩阵由两个记账组件组成，在此称为资产端和稳定端。资产端跟踪 LP 在池中对价格变动的敞口份额，而稳定端跟踪其在池中以稳定币计价的价值份额。这两个组件共同决定如何跟踪和结算 LP 的价值。

至关重要的是，这些组件不是作为静态快照存储的。每次发生交易时，PerpPair 都会更新其全局流动性状态，并且每个 LP 的重建余额是从累积的全局值与 LP 的入口快照之间的差额得出的。这种会计机制是在一次审计后重构中引入的，该重构用直接余额跟踪替换了原始的基于份额的累加器。然而，重构的减法路径引入了四舍五入的不对称性，可能导致在某些交易序列下重建的 LP 组件变为略微为负。

漏洞分析

易受攻击的 PerpPair 合约（0xb683...36ae17）包含两个复合漏洞。

1. 重构会计中的四舍五入不对称性。 引入直接余额跟踪的审计后重构，在减法重建路径中创建了四舍五入的不对称性。在某些交易序列下，四舍五入后的全局累积值可能略小于 LP 的入口快照，导致减法产生一个小的负结果而不是零。理论上，这个值应该接近零；这种不对称性是此重构实现特有的缺陷，而不是减法会计本身固有的属性。

2. 不安全的有符号到无符号类型转换。 在 getLpLiquidityBalance() 中，重建的 LP 余额组件从 int256 转换为 uint256 时未经验证。在 Solidity 中，将负的 int256 转换为 uint256 不会回滚；它会根据 2^256 取模来包装值，将 -1 这样的小负数转换为接近最大值的无符号整数 (2^256 - 1)。由于这个重建的余额用于 calcPnL() 进行结算，任何负输入都会被解释为巨额 LP 头寸，从而允许攻击者实现人为夸大的利润并从金库中提取资金。

单独来看，这两个漏洞都无法被利用。四舍五入的不对称性只产生一个略微为负的值，在正常的 int256 算术中，这只代表一个可以忽略的错误。但一旦该负值到达未经保护的类型转换，它就会包装成一个接近最大值的无符号整数。随后的边界检查将包装后的值限制在池的总资产端流动性，有效地将溢出转化为对市场整个资产端的声明。

攻击分析

以下分析基于攻击交易 0xcb0744...0c606447。

• 步骤 1：攻击者通过 Aave 闪电贷借入了 60,000 USDC。

• 步骤 2：一个辅助地址存入了 30,000 USDC 作为抵押品，并添加了 19,980 稳定币的仅稳定币 LP 头寸。仅存入稳定端，辅助地址确保其资产端 LP 组件接近零，使其更容易进入负值区域。

• 步骤 3：第二个辅助地址存入了 15,000 USDC 并开立了一个 100,000 名义的看涨头寸，导致 liquidityM 更新，引入了关键的四舍五入错误。相对于池的流动性，名义规模较大，放大了每次交易的四舍五入影响，将第一个辅助地址的资产端重建余额推至略低于零。

• 步骤 4：第一个辅助地址随后调用了 realizePnL()。在 LP 余额重建过程中，负的 lpAssetBalance 被包装成接近最大值的 uint256。然后，该大值被限制在市场的全部资产端流动性，产生了极高的利润。实际上，协议认为 LP 拥有市场的整个资产端。

• 步骤 5：攻击者从金库中提取了夸大的盈亏。

重复相同的模式，直到剩余的金库流动性被耗尽。偿还闪电贷后，攻击者实现了约 16.56 万美元的利润。

结论

此漏洞最终是由有符号到无符号转换中缺少边界验证造成的。直接的修复很简单：将裸露的类型转换替换为 SafeCast.toUint256()，它在输入为负数时会回滚，而不是包装。

更广泛地说，此事件说明了审计后重构绕过外部审查的风险。根据官方事后分析，在最后一次外部审计之后，当团队用直接余额跟踪替换原始累加器时，引入了四舍五入的不对称性。虽然重构解决了溢出问题，但它创建了一个内部测试未捕捉到的新边缘情况。当协议重构核心会计逻辑时，新代码路径应被视为安全关键并重新审计，特别是在重建值直接馈入盈亏结算或提款逻辑时。

本周更多事件

HB Token 事件

2026 年 4 月 7 日，BNB Chain 上的一个定制 ERC-20 代币 HB，其具有嵌入的买入/卖出钩子，被利用，损失约 19.3 万美元。根本原因在于有缺陷的奖励结算逻辑：触发时，它会调用 swapBack()，该函数直接从 PancakeSwap 池中移除 HB 储备，然后调用 sync() 来重新定价池。攻击者买光了池中大部分 HB 后，后续的 swapBack() 执行进一步减少了剩余的流动性，并急剧推高了现货价格。然后，攻击者将极少量 HB 卖入扭曲的池中，以获得不成比例的大量 USDT，循环往复直到池被耗尽。

背景

HB 是 BNB Chain 上一个定制的 ERC-20 代币，在 _transfer() 中嵌入了买入和卖出钩子。当用户从 AMM 池购买时，_handleBuy() 记录成本基础信息。当用户卖出时，_handleSell() 根据池的状态分支到不同的税费和结算路径。

该代币还包含一个奖励结算机制，可以触发 swapBack()。swapBack() 不执行正常的路由器中介交换，而是将 HB 直接从 PancakeSwap 池转移到 PROOF 地址，然后强制池通过 sync() 重新同步。这使得合约可以在正常的 AMM 交易流程之外收缩池的 HB 储备，并立即向上重新定价池。

漏洞分析

HB 代币合约（0x62ce...87a4b0）中的核心缺陷在于 swapBack() 通过直接从 AMM 池提取奖励，而不是从金库或通过路由器中介交换。由于 swapBack() 可以通过奖励结算路径到达，一个非交易代码路径可以绕过正常的 AMM 交易流程，直接改变池的储备并影响现货价格。

当池的 HB 储备较低时，调用 swapBack() 会进一步减少剩余的 HB 并放大价格扭曲，使得以极高的价格出售少量 HB 成为可能。

攻击分析

以下分析基于攻击交易 0x19671f...d71594ed。

• 步骤 1：攻击者从 Venus 借入大量资金。

• 步骤 2：攻击者向代币合约转入了约 1,496 HB，增加了合约的 HB 余额，以便后续的 swapBack() 可以从池中提取更多金额。

• 步骤 3：通过向 PancakeSwap 池转移一小部分 HB，攻击者触发了 _swapAndLiquify()，该函数将代币合约持有的约 4,163 HB 兑换成 10 USDT，并增加了攻击者可认领的 HB 奖励。

• 步骤 4：然后，攻击者花费 72,117,360 USDT 购买了 73,608,753 HB，导致池中剩余的 HB 流动性非常少。

• 步骤 5：接下来，攻击者触发了奖励短缺路径。为了满足奖励，代币调用了 swapBack()，该函数从 PancakeSwap 池中提取了额外的 HB 并强制 sync()，急剧推高了 HB 的价格。

• 步骤 6：攻击者直接将 USDT 转入池中以补充其 USDT 储备，然后以扭曲的价格仅出售 0.000582 HB，换取 37,582,322 USDT。

通过重复步骤 6 以扭曲的价格出售 HB 代币，攻击者提取了池中几乎所有的 USDT。

结论

HB 代币事件说明了允许奖励逻辑直接改变 AMM 储备的危险性。影响储备的函数绝不应该能从奖励结算路径访问，并且协议应避免在安全敏感的控制流中混淆内部代币余额和 AMM 储备会计。任何依赖于在内部扰动池后的现货 AMM 定价的设计都容易受到价格操纵。

Squid Multicall 事件

2026 年 4 月 7 日，一名 Squid 用户 在多个链上因与批准相关的事件损失了约 51.7 万美元。该用户错误地批准了 SquidMulticall 合约，而不是预期的 Squid Router。这使得攻击者能够调用一个无需许可的 SquidMulticall.run() 函数来执行任意外部调用。因此，攻击者可以使用任何已批准给该合约的额度来执行针对已批准该合约的用户的代币 transferFrom() 调用。

背景

在 Squid 的正常流程中，用户应批准 Squid Router，而 SquidMulticall 仅作为执行辅助。该辅助合约旨在作为路由逻辑的一部分执行批量调用，但不应是用户直接批准代币转移的支出方。

由于 ERC-20 额度检查仅针对支出方地址执行，任何结合了用户批准和不受限制的任意调用能力的合约都会成为一个危险的批准接收器：一旦被批准，该合约就可以成为一个通用的代币提取向量，如果任何人都可以控制它执行的调用。

漏洞分析

此事件并非由智能合约漏洞引起。损失是由于两个条件同时发生造成的：一个错误的批准指向了 SquidMulticall 而不是 Router，以及 run() 的无许可设计接受来自任何调用者的任意目标和 calldata。

SquidMulticall 旨在作为 Router 流程的下游步骤执行批量调用，其中输入由可信的路由逻辑构建。按预期使用时，无许可设计没有风险。但错误的批准完全改变了这种情况：一个 MEV 机器人检测到了有效的额度，调用了 run() 并附带了精心设计的 calldata 来调用 transferFrom(victim, attacker, amount)，并在没有受害者进一步操作的情况下，跨每个链提取了已批准的资产。

攻击分析

该事件影响了BNB Chain、Arbitrum、Optimism、Avalanche 和 Base 上的一个用户。以下分析基于攻击交易 0x81d0c4...9b1301e9。

• 步骤 1：受害者（0xacc0...f40e98）错误地批准了 SquidMulticall 而不是预期的 Squid Router。

• 步骤 2：一个 MEV 机器人检测到此额度并调用了 SquidMulticall.run() 并附带了精心设计的 calldata。

• 步骤 3：通过任意调用，SquidMulticall 调用了 transferFrom(victim, attacker, amount) 并从受害者钱包中转移了已批准的资产。

结论

此事件说明了无许可的任意调用合约与面向用户的批准流程并存的风险。直接原因是错误的批准，并且由于 SquidMulticall 接受无限制的调用者、任意目标和任意 calldata，任何错误地指向它的批准都立即且完全可被利用。使用执行辅助合约的协议应考虑添加调用者限制或约束此类函数允许的调用目标，以免错误的批准被轻易武器化。

XBIT 事件

2026 年 4 月 11 日，BNB Chain 上的 XBIT 代币被利用，损失约 5.3 万美元。根本原因在于 XBITVault 中一个故障安全（fail-open）的访问控制漏洞：transfer() 函数的授权检查是条件性的 — 它仅在 xbitContract 非零时才强制执行 msg.sender == xbitContract，否则静默通过。由于从未调用 bindXBIT() 来初始化合约，此漏洞永久暴露，允许任意调用者从任何地址转移 XBIT 余额，包括 XBIT/USDT PancakeSwap 池。攻击者利用这一点耗尽了池中的 XBIT，然后反复将少量 XBIT 卖回池中，以换取不成比例的大量 USDT。

背景

XBITVault 不是一个被动的金库合约。它是 XBIT 代币系统的余额和额度后端，暴露了类似代币的函数，如 transfer()、approve() 和 mintForXBIT()。按照预期设计，所有者必须首先调用 bindXBIT() 来初始化金库，设置 xbitContract、pancakePair、pairContract 和 xbitDecimals。初始化后，敏感的改变状态的函数应该只能由绑定的 XBIT 合约调用。换句话说，金库的安全模型依赖于在公开使用之前成功初始化。

漏洞分析

关键漏洞在于易受攻击的 XBITVault 合约（0xc879...42391a）中的访问控制是条件性的。transfer() 函数仅在 xbitContract != address(0) 时才检查 msg.sender == xbitContract。这意味着当 xbitContract 未设置时，该函数不会回滚，而是任何人都可以公开调用。由于余额存储在 _balances 中，任何外部调用者都可以从任何地址将 XBIT 转移到任何其他地址，只要源地址有足够的余额。

预期的初始化路径是 bindXBIT()，但由于从未调用，金库一直处于未初始化和故障安全状态。结果是有效地暴露了一个无限制的任意余额转移原语。

攻击分析

以下分析基于攻击交易 0xbc877f...4df1b694。

• 步骤 1：通过无限制的 transfer() 函数，攻击者从 XBIT/USDT 池中转移了 1,526,216.569 XBIT，而没有提供任何相应的 USDT。

• 步骤 2：攻击者调用 sync()，将池的 XBIT 储备压缩至仅 1-2 个单位。

• 步骤 3：在池中剩余近乎零的 XBIT 流动性后，攻击者反复出售 XBIT，从池中提取了约 53,112 USDT。

结论

此事件是由一个依赖于初始化的访问控制检查（故障安全）引起的。每当 xbitContract 未设置时，transfer() 都是无限制的，并且由于从未调用 bindXBIT()，金库永久暴露了一个公共的任意余额转移原语。特权函数在初始化完成之前应该回滚，并且部署时的绑定步骤应该是链上强制的前提条件，而不是操作上的假设。