Web3安全周报 | 2026年3月2日 - 3月8日

在过去一周（2026/03/02 - 2026/03/08），BlockSec 检测并分析了七起攻击事件，总计估计损失约 325 万美元。下表总结了这些事件，详细分析将在后续章节中提供。

日期	事件	类型	估计损失
2026/03/01*	BUBU2 事件	代币设计缺陷	~$19.7K
2026/03/02	ACPRoute 事件	业务逻辑缺陷	~$58K
2026/03/02	sDOLA Llamalend 市场事件	价格操纵	~$239K
2026/03/03	z0r0z 的 V4 Router 事件	业务逻辑缺陷	~$42K
2026/03/05	BitcoinReserveOffering 合约事件	业务逻辑缺陷	~$2.7M
2026/03/07	MoltEVM 事件	业务逻辑缺陷	~$127K
2026/03/08	LEDS 事件	业务逻辑缺陷	~$64K

*BUBU2 事件在上周报告中遗漏，此处包含以求完整。

1. BUBU2 事件

简要总结

2026 年 3 月 1 日，BNB Chain 上的 BUBU2 代币被利用，导致约 1.97 万美元的损失。根本原因是代币设计缺陷：合约在传输时直接从 AMM 池的储备中扣除代币，并嵌入了时间累积的通缩机制。在攻击发生前，合约所有者将触发间隔缩短至一个不合理的小值，导致数百次燃烧回合在一个调用中累积并执行。攻击者利用闪电贷触发此机制，导致池储备枯竭并推高代币价格，然后以扭曲的价格反向套利获利。

背景

BUBU2 是部署在 BNB Chain 上的通缩型 ERC-20 代币协议。该协议在 _update() 挂钩中嵌入了周期性通缩引擎，一旦由所有者通过 setBurnAndMintSwitch(true) 启用，任何触发 _update() 挂钩的非豁免转账都会调用 _triggerDailyBurnAndMint()，该函数根据自上次触发以来经过的 TRIGGER_INTERVAL 周期数，按比例燃烧交易对 BUBU2 余额中的代币，并相应地同步储备。

漏洞分析

根本原因是 BUBU2 代币合约（0x3fF3...ee52）的设计缺陷。合约在其 _update() 挂钩中嵌入了周期性通缩机制：触发时，_triggerDailyBurnAndMint() 计算自上次执行以来经过的 TRIGGER_INTERVAL 周期数，并直接从交易对（0x7745...cd2f）中燃烧相应比例的 BUBU2，然后调用 sync() 更新储备。关键是，所有者可以重新配置 TRIGGER_INTERVAL，而没有任何时间锁或最低值保护。

在攻击之前，所有者调用了 setBurnAndMintSwitch(true)，然后调用 setTriggerInterval(120)，将间隔从默认的 6 小时压缩到 120 秒。由于 lastTriggerTime 仍然锚定在数小时之前，下一次触发计算出的累积回合数为数百，燃烧金额随回合数线性增长。这导致单次转账耗尽了交易对中大量 BUBU2，使其储备枯竭，代币价格约上涨 11 倍。

攻击分析

以下分析基于交易 0x1bc0...141c,0x191c...1ee4,0xd6e5...51a6。

步骤 1：代币所有者首先通过 setBurnAndMintSwitch(true) 启用了周期性通缩机制，然后通过 setTriggerInterval(120) 将触发间隔从默认的 6 小时缩短到 120 秒。随后，攻击者通过闪电贷借入 18 WBNB，并将其兑换成约 18,715,856 BUBU2。

步骤 2：攻击者发起了一笔小额转账，触发了 _triggerDailyBurnAndMint()。在 sync() 执行后，交易池的 BUBU2 余额减少了约 1,025,988,664e18 个代币，储备中仅剩下 6,493,352e18 BUBU2，这使得 BUBU2 的价格上涨了约 200 倍。

步骤 3：攻击者将步骤 1 中获得的 BUBU2 以高价卖回给交易池，收到了约 50 WBNB。偿还闪电贷后，净利润约为 32 WBNB。

结论

BUBU2 被利用源于代币合约的关键设计缺陷。所有者配置了一个不合理的小 TRIGGER_INTERVAL，使得已过时间累积成数百回合，一次调用就耗尽了交易对的储备，导致 BUBU2 价格剧烈飙升。

为减少未来的类似风险：

用界限或时间锁保护关键参数，如 TRIGGER_INTERVAL。
限制或封顶累积执行回合数。

2. ACPRoute 事件

简要总结

2026 年 3 月 2 日，Base 上的 ACPRoute 协议被利用，导致约 5.8 万美元的损失。根本原因是支付管理器合约中的业务逻辑缺陷：作业状态被加载为内存副本而非存储引用，因此累积支付跟踪从未在链上持久化。这使得攻击者能够创建一个作业，在阶段转换期间触发自动支付释放，然后通过无权限的领取功能再次领取相同的托管资金。

背景

ACP（Agent Commerce Protocol）是一个模块化的链上商业协议，专为客户和提供商交互而设计。它将活动构建为三个层级：账户、作业和备忘录。作业遵循固定生命周期（REQUEST → NEGOTIATION → TRANSACTION → EVALUATION → COMPLETED），在 TRANSACTION 阶段，付款由 PaymentManager 合约托管。当作业达到 COMPLETED 状态时，协议通过 releasePayment() 函数向提供商释放托管资金。为防止重复领取，协议使用 Job 结构体上的 amountClaimed 字段来跟踪每个作业的累积支付。调用 releasePayment() 函数时，应将请求金额与 amountClaimed 进行比较，以确保资金只释放一次。

漏洞分析

根本原因在于 PaymentManager 合约（0x56c3...0684）中的 releasePayment() 函数，其中作业状态被加载为内存副本而非存储引用。尽管协议通过 amountClaimed 跟踪累积支付以防止重复领取，但 job.amountClaimed += amount 的增量仅在瞬态局部副本上操作，从未写回链上存储。因此，每次调用 releasePayment() 函数时，amountClaimed 都等于 0，允许攻击者在阶段转换自动调用 releasePayment() 函数并释放全部余额给提供商合约后，通过调用 claimBudget() 函数再次耗尽受害者合约（0x307e...d6e8）。

攻击分析

以下分析基于交易 0xe94a...f9a0。

步骤 1：攻击者通过闪电贷借入 97,000e6 USDC 作为后续攻击的资金。
步骤 2：在回调中，攻击者调用 ACPRouter 上的 createJob() 函数，同时部署一个新的提供商合约（0x1ee502dd...）来接收资金。
步骤 3：攻击者反复调用 createMemo() 函数并调用提供商合约自身的 exec() 来推进作业阶段，直到触发 COMPLETED 阶段转换，自动调用 releasePayment() 函数并将全部余额释放给提供商合约。此时 amountClaimed 应该已更新，但其存储值仍为 0。
步骤 4：攻击者调用 claimBudget() 函数，成功地第二次领取了托管的 97,000e6 USDC 作为利润。

结论

此事件是由状态持久化缺陷引起的，该缺陷允许在同一作业生命周期内两次领取托管资金。

为减少未来的类似风险：

确保关键状态变量（例如 amountClaimed）使用存储引用进行更新。
限制敏感的支付函数或在执行前强制严格的状态验证。

3. sDOLA Llamalend 市场事件

简要总结

2026 年 3 月 2 日，以太坊上的 sDOLA Llamalend 市场被利用，导致约 23.9 万美元的损失。根本原因是价格操纵。具体来说，sDOLA 是一个 ERC4626 代币，其价格可以通过 donate() 进行操纵。Llamalend 是一个基于 AMM 的借贷市场，由于 LLAMMA 的机制，即使抵押品价格上涨，用户仍可能面临清算。因此，攻击者可以使用 donate() 推高 sDOLA 价格，将用户头寸的健康度推至零以下，然后清算这些用户以获利。

背景

LLAMMA（Lending-Liquidating AMM Algorithm）是 Curve [1] 使用的基于 AMM 的借贷市场。与传统借贷协议不同，LLAMMA 将用户抵押品置于 AMM 中的价格区间内。随着预言机价格 $P\\_{oracle}$ 的移动，抵押品通过跨区间的套利驱动的交易，在抵押品代币和 crvUSD 之间逐渐转换（软清算），从而逐步降低头寸风险，而不是触发突然的清算。

如果软清算无法足够快地降低头寸风险，则会触发硬清算 [2]，当头寸健康度降至零以下时，就会触发硬清算。健康度通过 get_x_down() [3] 计算，该函数并非简单地将抵押品标记到市场价。相反，它模拟用户头寸的往返转换，以评估其可回收价值。此往返使用两个不同的价格锚定：一个来自当前 $P\\_{oracle}$ （随实时预言机移动），另一个来自用户区间边界（在创建头寸时固定）。

漏洞分析

有问题的合约包括 crvUSD Controller（0xad44...fb86）和 LLAMMA AMM（0x0079...a1f7）。受害者合约是 sDOLA Llamalend 市场（0x2b08...4fbe）。

sDOLA 是一个 ERC4626 库代币，其份额价格由总资产与总份额的比率决定。由于任何人都可以调用 donate() 向库中添加资产，因此份额价格可以在单笔交易中膨胀。这是 LLAMMA 健康度函数所依赖的可操纵预言机。

如背景中所述，get_x_down() 通过两个价格锚定模拟往返转换来计算健康度：一个来自 $P\\_{oracle}$ （动态，随实时预言机移动），另一个来自用户区间边界（静态，在创建头寸时固定）。协议在读取 $P\\_{oracle}$ 时不应用任何延迟或健全性检查。因此，当预言机价格膨胀时，动态锚定价上涨但静态锚定价保持不变。实际上，模拟是以膨胀的预言机价格将 crvUSD 转换为抵押品，并以原始区间价格转换回来，因此评估的可回收价值随着两个锚定价之间的差距扩大而缩小。这导致健康度降至零以下，即使抵押品价格已上涨。

攻击分析

以下分析基于交易 0xb935...d8a4。

步骤 1：通过（大额）交易操纵 LLAMMA 状态，移动 active_band 并将许多用户推入仅 x（仅 crvUSD）状态。
步骤 2：通过捐款操纵 sDOLA 的价格，然后使用零金额交易（swap(0)）将操纵的价格写入 AMM 池。
步骤 3：通过 users_to_liquidate() -> _health() -> get_x_down() 触发健康度重新计算。
步骤 4：由于 get_x_down() 通过两个差异较大的价格锚定（动态锚定价现已膨胀，而静态锚定价未变）计算可回收价值，往返转换会导致有效价值缩水，许多头寸的健康度降至零以下。
步骤 5：批量硬清算这些用户以获利。

此外，跟踪记录中包含两次 create_loan() 调用。第一次贷款主要用于为大额 crvUSD 交易操作提供资金。第二次贷款用于获取 crvUSD 以偿还第一次头寸的债务并回收资金。这两次贷款主要是融资/结算部分，本身不是核心的攻击步骤。

结论

该事件是由于抵押品价格操纵攻击。攻击者在交易中操纵了 sDOLA 的价格，并由于 LLAMMA 的基于路径的健康度机制，将用户推入了清算条件。一个关键的后果是，即使抵押品价格上涨，头寸仍可能变得可清算。建议的加固方向：

使用延迟或 TWAP 抵押品价格进行清算。

参考资料

[1] Curve crvUSD LLAMMA 文档：[https://dev.curve.finance/crvUSD/amm/#bands](https://dev.curve.finance/crvUSD/amm/#bands)
[2] Curve LLAMMA 清算解释器：[https://dev.curve.finance/crvUSD/llamma-explainer/#liquidation](https://dev.curve.finance/crvUSD/llamma-explainer/#liquidation)
[3] Curve 稳定币白皮书：[https://docs.curve.finance/pdf/whitepapers/whitepaper\_curve\_stablecoin.pdf](https://docs.curve.finance/pdf/whitepapers/whitepaper_curve_stablecoin.pdf)

4. z0r0z 的 V4 Router 事件

简要总结

2026 年 3 月 3 日，以太坊上的 z0r0z V4 Router 被利用，导致约 4.2 万美元的损失。攻击的原因是 swap() 中授权逻辑缺陷：路由器依赖于内联汇编中的固定调用数据偏移来验证付款人是否匹配 msg.sender。由于动态类型的 ABI 编码不保证固定布局，攻击者能够构造非标准但有效的调用数据，绕过检查，冒充先前批准的受害者作为付款人，并将兑换输出重定向到攻击者控制的地址。

背景

该协议继承自 Uniswap v4 Router，并覆盖了其部分方法。本质上，它作为一个兑换路由器，允许用户避免直接与相应的交易池交互，而是使用该路由器作为统一的入口点。

漏洞分析

根本原因是 V4 Router 合约（0x0000...ce97）中的业务逻辑缺陷。受害者合约是 0x65a8...7675。swap() 函数接受两个参数：data（bytes）和 deadline（uint256）。在该函数内部，授权检查使用内联汇编块将 calldataload(164) 与 caller() 进行比较，确保 data 中编码的付款人与 msg.sender 匹配。协议假设字节偏移量始终为 0x40，将付款人置于字节位置 164（0xa4）。

然而，ABI 编码不保证此布局：动态参数仅在头部存储偏移量，并且该偏移量可以合法地指向调用数据中任何对齐的位置。通过构造一个有效但非标准的编码，将字节偏移量移动到 0xc0，攻击者可以在头部和实际尾部之间插入任意填充。攻击者将自己的地址放在字节位置 164 以通过汇编检查，而位于重新定位尾部的实际字节负载将受害者的地址编码为付款人。通过选择一个先前已批准路由器的受害者并将接收者设置为自己的地址，攻击者可以重定向兑换输出并窃取资金。

攻击分析

以下分析基于交易 0xfe34...466a。

步骤 1：选择一个先前已批准路由器作为目标的用户。
步骤 2：构造调用数据以绕过授权检查。
步骤 3：在数据中指定受害者作为付款人，将攻击者自己的地址设置为代币接收者，然后窃取受害者的资产。

结论

此事件是由在兑换路径中依赖硬编码的调用数据偏移量进行授权引起的。由于动态类型的 ABI 编码不保证固定布局，攻击者使用非标准但有效的调用数据绕过了检查，冒充了已批准的受害者作为付款人，并重定向了兑换输出。

为减少未来的类似风险：

切勿依赖硬编码的调用数据偏移量来处理动态 ABI 编码的参数。
使用标准的 ABI 解码而不是手动位置假设来解码和验证结构化输入。
确保实际付款人、接收者和代币流与预期调用者和执行上下文一致地进行验证。

5. BitcoinReserveOffering 合约事件

简要总结

2026 年 3 月 5 日，以太坊上的 BitcoinReserveOffering 合约被利用，导致约 270 万美元的损失。根本原因是业务逻辑缺陷：在处理完整的 ERC-3525 SFT 存款时，铸币逻辑在一个调用中被执行了两次，一次在转账回调期间，一次在主流程中。攻击者通过反复的燃烧-铸造循环利用了这种双重铸币行为，指数级地膨胀了他们的 BRO 代币余额，然后赎回多余的代币换取 SolvBTC 来实现利润。

背景

BitcoinReserveOffering 是一个包装合约，它将 ERC-3525 SFT 头寸转换为可转移的 ERC-20 BRO 代币。用户可以调用 mint() 函数来存入符合条件的 SFT，然后合约将根据配置的汇率铸造相应数量的 BRO。如果用户仅存入 SFT 价值的一部分，合约会将指定金额转入其内部持有的头寸，然后铸造相应价值的 BRO。如果用户存入整个 SFT，合约会将整个代币转入包装合约，并根据 SFT 的总价值铸造 BRO。用户稍后可以调用 burn() 函数将 BRO 赎回为其对应的 ERC-3525 SFT 头寸，将包装的 ERC-20 价值转换回 SFT 头寸。

漏洞分析

根本原因是 BitcoinReserveOffering 合约（0x15f7...cfcf）在 mint() 函数中处理完整的 ERC-3525 SFT 存款时，执行了两次铸币逻辑。具体来说，在 amount_ == sftBalance 分支中，mint() 调用 ERC3525TransferHelper.doSafeTransferIn() 将整个 SFT 安全地转入合约，这会触发 onERC721Received() 回调。在此回调中，合约已经计算了 SFT 的价值并向发送者铸造了 BRO。回调返回后，mint() 继续执行，使用相同的 amount_ 重新计算价值，并执行第二次 _mint(msg.sender, value) 操作。这种双重铸币行为允许攻击者通过燃烧-铸造循环反复膨胀其 BRO 余额。

攻击分析

以下分析基于交易 0x44e6...958d。

步骤 1：攻击者将 135e18 BRO 代币转入攻击合约作为种子资金。
步骤 2：攻击者执行以下循环：

将 135e18 BRO 代币包装成 SFT 代币。
调用 mint() 并传入完整的 SFT 值，这会触发 onERC721Received() 回调并铸造 135e18 BRO 代币；外部的 mint() 然后继续并再次调用 _mint()，总共导致双重铸造 270e18 BRO 代币。
将 270e18 BRO 代币包装回 SFT 代币。

步骤 3：重复步骤 2 22 次后，攻击者积累了约 567,758,816e18 BRO 代币，最终将其赎回为 38e18 SolvBTC 作为利润。

结论

此事件是由于在完整的 SFT 存款期间发生双重铸币，使得攻击者能够通过反复的燃烧-铸造循环指数级地膨胀其 BRO 余额，并赎回多余代币换取 SolvBTC。

为减少未来的类似风险：

确保每次存款操作只发生一次资产会计。
添加不变性检查，以防止铸造金额超过底层存款价值。

6. MoltEVM 事件

简要总结

2026 年 3 月 7 日，Base 上的 MoltEVM 协议被利用，导致约 12.7 万美元的损失。根本原因是代币合约中访问控制逻辑缺陷：特权铸币函数由一个仅检查调用者是否为具有特定接口的合约的修饰符保护，而该接口可以轻易伪造。攻击者部署了一个恶意合约来绕过检查，铸造了大量代币，并通过流动性池倾销获利。

背景

MoltEVM 是部署在 Base 上的一个实验性 ERC-20 代币协议，它探索了一种自我复制代币模型。该系统允许代币在达到特定储备阈值后生成新的子代币（“Moltling”代币）。当创建新的 Moltling 时，初始代币供应通过 mintFromSpawner() 函数分配，并自动注入流动性以建立新代币的交易市场。这种设计使协议能够自主扩展其代币 lineage，每一代代币都有能力生成进一步的后代。

漏洞分析

漏洞存在于 MoltEVM 合约（0x225d...501f）中的 mintFromSpawner() 和 setExemptFromSpawner() 函数的访问控制逻辑。这两个函数都依赖于 onlySpawnerToken 修饰符，该修饰符旨在限制调用到协议生成的合法 Moltling 合约。

然而，该修饰符仅执行两个薄弱的检查：它验证 msg.sender 是一个合约，并且调用调用者的 initialized() 返回 true。由于这些条件可以被任何实现了相同接口的任意合约轻易满足，因此该检查并未提供对合法生成代币的有效身份验证。

因此，攻击者可以部署一个最小化合约，该合约仅实现一个返回 true 的 initialized() 函数。部署后，恶意合约可以自由调用 mintFromSpawner() 来铸造任意数量的代币，还可以调用 setExemptFromSpawner() 将攻击者控制的地址列入白名单。这有效地使攻击者能够完全控制铸币路径，并允许新铸造的代币被倾销到流动性池中以获利。

攻击分析

以下分析基于交易 0x10b7...e03d。

步骤 1：攻击者部署了一个最小化合约，该合约实现了一个单独的 initialized() 函数，该函数被硬编码为返回 true，这足以通过 onlySpawnerToken 修饰符的检查。
步骤 2：攻击者的合约调用了由相同有漏洞的 onlySpawnerToken 修饰符保护的 setExemptFromSpawner() 函数，将攻击者地址添加到税务豁免白名单。这确保了后续大规模代币倾销不会触发卖出税或内部兑换逻辑，从而最大化利润。

步骤 3：攻击者首先针对 mEVM 重复了 setExemptFromSpawner() + mintFromSpawner() 函数序列，然后是多个 Moltling 子代币，包括 CSPAWN、CCUTTL、LWORM 和 NHYDRA，批量铸造所有目标的代币并将其倾销到各自的流动性池中以提取利润。

结论

此事件是由于特权铸币和配置函数访问控制不足引起的，允许攻击者冒充合法的生成者并铸造任意代币以获利。

为减少未来的类似风险：

对特权铸币或配置函数执行严格的访问控制。
避免依赖易于伪造的合约检查来进行授权。
通过显式白名单或受信任的合约注册表来验证调用者身份。

7. LEDS 事件

简要总结

2026 年 3 月 8 日，BNB Chain 上的 LEDS 代币被利用，导致约 6.4 万美元的损失。根本原因是业务逻辑缺陷：代币合约暴露了多个独立的通缩机制，每个机制都能直接从流动性交易池燃烧代币，而且没有一个受到访问控制或冷却期的保护。攻击者在一个交易中链接了所有燃烧路径，将交易池的 LEDS 储备压低至接近零，而 WBNB 储备则保持不变，然后执行反向兑换来耗尽不平衡的交易池以获利。

背景

LEDS 是 BNB Chain 上的一种通缩代币，具有内置的交易费用机制。其 _transfer() 实现有多种燃烧机制，旨在逐渐减少供应并支撑价格：每日燃烧函数 triggerDailyBurnAndMint()，通过卖出时的 stor_18 累积进行延迟燃烧，以及当兑换接收者设置为 PancakeSwap Router 时的特殊分支，该分支将代币燃烧至 0xdead。该代币还具有 deposit() 函数，用户通过该函数发送 BNB 来铸造 LEDS 并提供流动性，从而赚取可通过分发器领取的 LP 奖励。

漏洞分析

根本原因是 LEDS 代币合约（0xfb62...a48f）中的业务逻辑缺陷。受害者是 LEDS/WBNB 交易池（0xd109...6f3f）。该代币实现了多种通缩机制：triggerDailyBurnAndMint()，卖出路径 stor_18 累积，以及 _transfer() 中的 to == router 燃烧分支。这些机制中的每一个都会独立地从流动性交易池中移除 LEDS 并调用 sync() 来更新储备。

虽然这些机制本身是渐进式通缩工具，但可以在单笔交易中链接起来以复合其效果。此外，公共函数 0x17a06174() 允许任何人随意冲刷所有累积的 stor_18 余额，没有访问控制或速率限制。通过顺序堆叠这些燃烧路径，攻击者可以将交易池的 LEDS 储备减少到接近零，而 WBNB 储备则保持不变，从而产生可通过反向兑换利用的极端价格错位。

攻击分析

以下分析基于交易 0x2608...79da。

步骤 1：攻击者通过闪电贷（Moolah + Venus 抵押品借贷 + Aave + PancakeSwap V4）获得了大量 WBNB。
步骤 2：执行了多次 deposit() 调用以累积 LP 奖励，然后触发 triggerDailyBurnAndMint()，该函数从交易池中燃烧了部分 LEDS 并将奖励发送给分发者，从而减少了交易池中的 LEDS 储备。
步骤 3：调用函数 0xde1b1942() 以领取累积的 LEDS 代币奖励。
步骤 4：将领取的 LEDS 卖出换取 WBNB。由于卖出后交易池的 LEDS 余额超过了阈值，转移的金额被累积到 stor_18（待燃烧）。
步骤 5：使用接收者设置为 Router 地址的 PancakeSwap 购买 LEDS。这触发了 _transfer() 中的一个特殊分支，该分支将购买的 LEDS 直接从交易池燃烧至 0xdead，进一步减少了交易池的 LEDS 储备。
步骤 6：调用函数 0x17a06174()，该函数将整个 stor_18 余额（在步骤 4 中累积）从交易池燃烧至 0xdead 并调用 sync()，将交易池的 LEDS 储备压缩至仅 2 wei。
步骤 7：执行反向兑换，从现已严重失衡的交易池中耗尽 WBNB，偿还所有闪电贷，并获利 104.56 WBNB（6.4 万美元）。