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 代币遭到利用，导致约 19.7 千美元的损失。根本原因是代币设计缺陷：合约在转账时，其内置的具有时间累积的通缩机制会直接从 AMM 池的储备中扣除代币。在攻击发生之前，合约所有者将触发间隔缩短到一个不合理的短值，导致数百次销毁轮次在一个调用中累积并执行。攻击者利用闪电贷触发了此机制，导致池储备枯竭并推高了代币价格，然后以扭曲的价格反向兑换获利。

背景

BUBU2 是部署在 BNB Chain 上的通缩型 ERC-20 代币协议。该协议在 burnAndMintSwitch 的控制下嵌入了一个周期性的通缩引擎：一旦由所有者通过 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，耗尽了其储备，并将 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 协议遭到利用，导致约 58 千美元的损失。根本原因是支付管理器合约中的业务逻辑缺陷：作业状态被加载为内存副本而不是存储引用，因此累积的支付跟踪从未持久化到链上。这使得攻击者能够创建一个作业，在阶段转换期间触发自动支付释放，然后通过无权限的领取功能第二次领取相同的托管资金。

背景

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 市场遭到利用，导致约 239 千美元的损失。根本原因是价格操纵。具体来说，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 遭到利用，导致约 42 千美元的损失。攻击是由 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：攻击者执行以下循环：
1. 将 135e18 BRO 代币包装成 SFT 代币。
2. 调用 mint() 并传入完整的 SFT 价值，这会触发 onERC721Received() 回调并铸造 135e18 BRO 代币；外部的 mint() 然后继续并再次调用 _mint()，总共导致双重铸币 270e18 BRO 代币。
3. 将 270e18 BRO 代币重新包装成 SFT 代币。
步骤 3：重复步骤 2 22 次后，攻击者积累了约 567,758,816e18 BRO 代币，最终赎回 38e18 SolvBTC 作为利润。

结论

此事件是由于完整的 SFT 存款期间的双重铸币引起的，使得攻击者可以通过重复的销毁-铸币循环指数级地膨胀其 BRO 余额，并将多余的代币赎回为 SolvBTC。

为减少未来类似的风险：

确保每个存款操作只进行一次资产核算。
添加不变性检查，防止铸币金额超过底层存款价值。

6. MoltEVM 事件

简要摘要

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

背景

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

漏洞分析

漏洞存在于 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 及其多个 Moltling 子代币（包括 CSPAWN、CCUTTL、LWORM 和 NHYDRA）重复执行了 setExemptFromSpawner() + mintFromSpawner() 函数序列，批量铸造了所有目标的代币，并将它们抛售到各自的流动性池中以提取利润。

结论

此事件是由于对特权铸币和配置函数执行了不足的访问控制，导致攻击者能够冒充合法的生成者并为获利而铸造任意代币。

为减少未来类似的风险：

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

7. LEDS 事件

简要摘要

2026 年 3 月 8 日，BNB Chain 上的 LEDS 代币遭到利用，导致约 64 千美元的损失。根本原因是业务逻辑缺陷：代币合约暴露了多个独立的通缩机制，每个机制都能够直接从流动性池销毁代币，并且都没有访问控制或冷却保护。攻击者在一个交易中将所有销毁路径串联起来，将池的 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：通过 PancakeSwap 以接收者设置为 Router 地址购买 LEDS。这触发了 _transfer() 中的一个特殊分支，该分支将购买的 LEDS 直接从池中销毁到 0xdead，进一步减少了池中的 LEDS 储备。
步骤 6：调用函数 0x17a06174()，该函数将整个 stor_18 余额（在步骤 4 中累积）从池中销毁到 0xdead 并调用 sync()，将池的 LEDS 储备压缩到仅剩 2 wei。
步骤 7：执行反向交换以从现在严重失衡的池中耗尽 WBNB，偿还所有闪电贷，并获利 104.56 WBNB（64 千美元）。