Web3安全周报 | 2026年3月16日 – 3月22日

在过去的一周（2026/03/16 - 2026/03/22）中，BlockSec 共检测并分析了七起攻击事件，估算造成的总损失约为 8270万美元。下表总结了这些事件，详细分析请见后续各章节。

*Venus 事件未包含在上周的报告中，此处补全以保证完整性。

1. Venus 事件

简要总结

2026 年 3 月 15 日，Venus Protocol 在 BNB Chain 上的 THE (Thena) 市场遭到捐赠攻击与市场操纵的组合打击，导致约 215 万美元的坏账。THE 市场的供应上限仅适用于铸造路径，而直接向市场捐赠代币仍会增加余额 (cash) 并推高 exchangeRate（汇率）。攻击者随后利用这种虚高的抵押价值借出流动资产，在获取更多 THE 的同时拉高 THE 代币的市场价格，最终在头寸被强制清算后留下了坏账。

背景

Venus 是一个基于 Compound V2 分叉的借贷协议。在 THE 市场中，用户存入 THE 并获得 vTHE 代币。exchangeRate 决定了每个 vTHE 代表多少底层资产，其核心公式为：

exchangeRate = (cash + borrows - reserves) / totalSupply

其中 cash 为市场底层代币余额，borrows 为未偿还债务总额，reserves 为协议储备金，totalSupply 为 vTHE 总供应量。THE 市场还设有供应上限，旨在限制总抵押敞口。

漏洞分析

本次事件涉及针对 vTHE 市场合约 (0x86e0...739f) 的两个复合攻击向量。

捐赠攻击

该协议直接从市场合约的原始代币余额中获取 cash，这使其由于本质原因极易受到捐赠攻击。任何直接转入 vTHE 市场合约的 THE 都会增加 cash，从而提高 exchangeRate。攻击者利用这一点将 exchangeRate 提高了约 3.81 倍，放大了其现有 vTHE 头寸的抵押价值。

市场操纵

THE 代币的链上流动性不足，使其现货价格易受较小的买盘压力影响。协议的预言机旨在拒绝偏离参考价格过大的价格，在攻击期间，预言机确实有约 37 分钟拒绝了异常价格。然而，持续的买盘压力最终将 THE 代币价格推高至约 0.51 美元（约为攻击前价格的两倍），预言机最终采纳了该价格。

这两个矢量相互强化。捐赠攻击带来的虚高 exchangeRate 放大了每个 vTHE 单位的抵押价值，而操纵后的 THE 代币价格进一步提高了借贷能力。两者结合，使得攻击者能在一个超过供应上限 3.67 倍 的头寸上积累约 1490 万美元的贷款。

攻击分析

以下分析基于范例攻击交易 0xce6e3e...1f5fb0e。

• 第 1 步：一个与攻击者关联的钱包通过 TornadoCash 相关的 77 笔交易，在约九个月的时间里接收了 7,447 枚 ETH。这些 ETH 被存入 Aave 并借出约 992 万美元的稳定币，进而建立了约 1220 万 THE 的 vTHE 头寸，约为 1450 万 THE 供应上限的 84%。

• 第 2 步：在首次攻击交易中，6 个地址将约 3600 万 THE 直接转入 vTHE 市场合约。攻击合约还借入了 158 万 USDC 并重新存入，随后借出约 460 万 THE 并直接转入 vTHE。这使 exchangeRate 提高了约 3.81 倍。

• 第 3 步：在随后的交易中，攻击者借入了 CAKE、BNB、BTCB 和 USDC 等流动资产。攻击者不断用借来的资产购买 THE 并向 vTHE 捐赠更多 THE，形成了一个循环，既增加了头寸的借贷能力，也推高了 THE 代币的市场价格。

• 第 4 步：THE 代币价格从约 0.2 美元开始上涨，甚至短暂触及币安数据源的 4 美元价格。协议的预言机在约 37 分钟内拒绝了极值价格，最终接受了约 0.51 美元的价格。

• 第 5 步：截至 UTC+8 20:42，攻击者的头寸达到约 5320 万 THE，约为供应上限的 3.67 倍，总借贷敞口约为 1490 万美元。

• 第 6 步：该头寸随后触发了大额清算。在来自 254 个清算地址的 8,048 笔清算交易中，约 4200 万 THE 抵押品被清算。随着抛压持续，THE 代币跌至约 0.22 美元。清算所得无法覆盖全部债务，致使 Venus 产生了约 215 万美元的坏账。

结论

此次事件并未涉及任何新型漏洞。它展示了一个广为人知的攻击向量在被有条不紊地执行时，如何在协议层层设防的情况下击溃整个风险体系。链上预警信号已存在数月，但从检测到干预之间的真空地带仍未得到填补。通过引入具备流动性感知能力的风险参数、自动化断路器以及头寸级监控来缩小这一差距，是该事件留给其他借贷协议的主要教训。

有关详细分析，请参阅我们的深度拆解文章 [1]。

参考资料

• [1] https://blocksec.com/blog/venus-thena-donation-attack

2. dTRINITY 事件

简要总结

2026 年 3 月 17 日，以太坊上的 Aave V3 分叉借贷协议 dTRINITY 的 dLEND 借贷市场遭到攻击，损失约 25.73 万美元。根本原因是 Aave V3 分叉中固有的空市场 (empty market) 漏洞。当池中流动性近乎为零时，反复的闪电贷手续费累积会导致 liquidityIndex 达到极端值。一旦流动性记录被扭曲，攻击者便利用存取款路径中的精度缺失过度夸大抵押品价值，借出 dUSD 并收回已存入的 cbBTC，从而实现净利润。

背景

dTRINITY 包含 dUSD 稳定币系统和从 Aave V3 分叉而来的借贷市场 dLEND。核心合约 L2Pool (0xfda3...e19e84) 中，每种资产都有独立的储备金池，储备金会计基于缩放后的余额与流动性指数 liquidityIndex。用户的当前基础余额由缩放余额乘以储备金的标准化收入推算得出。

闪电贷手续费通过 cumulateToLiquidityIndex() 加入会计记录，公式为： nextLiquidityIndex = ((amount / totalLiquidity) + 1) * reserve.liquidityIndex

当 totalLiquidity 极小时，每一次手续费累积都会导致 liquidityIndex 以异常速度上涨。

漏洞分析

攻击的关键前提是 dLEND-cbBTC 市场 (0x504d...3acc) 存在几乎为空的储备金。一旦储备金被压缩到仅剩一个缩放份额，闪电贷手续费将不再分摊给庞大的供应基数，导致 liquidityIndex 极速膨胀。

当 liquidityIndex 被大幅放大后，底层资产向缩放余额的转换进入了一种极端的舍入区域。在这种状态下，较小的存款量可能铸造一个额外的份额，而规模大得多的提款却只能消耗一个份额。这种非对称性使得攻击者可以夸大 aCbBTC 抵押品价值，并从其他池借走真实的 dUSD，因为健康检查是在池级别进行的，而受损的 cbBTC 储备金直接影响了跨资产的借贷能力。

攻击分析

攻击由两笔交易构成：0x8d33d6...40ae7139 和 0xbec4c8...4fc33260。

交易 1：liquidityIndex 操纵

• 第 1 步：从 Morpho Blue 借入 cbBTC。
• 第 2 步：将 cbBTC 存入 dLEND-cbBTC 以铸造 100 个缩放份额。
• 第 3 步：提取 99 个份额，只剩下 1 个份额，将 dLEND-cbBTC 压缩至几乎为空的状态。
• 第 4 步：向 dLEND-cbBTC 的 aToken 转入 80,000,000 单位的 cbBTC（即 0.8 cbBTC）。
• 第 5 步：调用 150 次 Pool.flashLoan() 将手续费累积到会计记录中，将 liquidityIndex 提升至 622662199999999999999999999979728276。

• 第 6 步：执行重复的存取循环以提取剩余的储备金。
• 第 7 步：偿还闪电贷。

交易 2：利润实现

• 第 1 步：再次从 Morpho Blue 借入 cbBTC。
• 第 2 步：将约 7.72 cbBTC 存入已被操纵的储备金中，通过这种方式构建出夸大的 aCbBTC 抵押头寸。

• 第 3 步：利用夸大的抵押价值从 dLEND-dUSD 市场借出 257,328 dUSD。

• 第 4 步：通过持续的存取循环提取 cbBTC。

• 第 5 步：偿还 Morpho 闪电贷，并将借出的 dUSD 转移至攻击者 EOAS 地址。

结论

此次事件是 Aave V3 分叉中记录在案的“空市场攻击”。此模式已在多个协议中出现，且缓解方案已相当成熟。在储备金初始化时强制执行最小存入阈值，可以防止储备金进入难以控制的指数增长状态。因此，分叉 Aave V3 的协议应将启动资产准备视为关键环节，确保项目部署时即锁入有意义的流动性，而非依赖自然增长的存款来稳定指数。

3. Fun.xyz 事件

简要总结

2026 年 3 月 17 日，Polygon 上的结算基础设施协议 Fun.xyz 遭到攻击，损失约 8.57 万美元。根本原因是旧版 CheckoutPool 在没有任何访问控制的情况下公开了关键功能 bridge()，且未将桥接调用数据 (calldata) 绑定到预定的接收者。该漏洞允许攻击者将执行路径重定向到受信任的结算逻辑，并将资金转移到攻击者控制的智能账户中。

背景

CheckoutPool 是 Fun.xyz 结算基础设施的核心合约。在正常流程中，用户通过 deposit() 创建结账记录，受信任的操作员通过 bridge() 和 execute() 等结算路径推进进度。对于桥接操作，bridge() 会根据调用者提供的 bridgeParams.target 和 bridgeParams.callData 执行外部调用。

漏洞分析

根本原因是旧版 CheckoutPool (0x1304...2ec01a) 在没有任何适当访问控制的情况下，通过 bridge() 函数暴露了敏感结算路由路径，且未针对预定接收者验证外部提供的桥接调用数据。具体如下：

• 旧版实现未在 bridge() 上强制执行 onlyOperator，允许任何外部调用者在通过 deposit() 创建结账后发起调用。
• bridge() 将调用者提供的 bridgeParams 传递给 _bridgeToRecipient()，函数在未校验接收者是否符合结账记录的情况下执行了外部调用。

一个额外的运营条件使得该漏洞具备可操作性：在攻击发生时，旧版 CheckoutPool 仍在 CheckoutPaymaster 中保留了操作员权限。这使得精心编造的 bridge() 调用能够触发 CheckoutPaymaster.activateAndCall()，进而调用更新后的 CheckoutPool.execute() 路径，从而将资金转移到攻击者控制的地址。

攻击分析

以下分析基于攻击交易 0x957bcf...1f4f5a。

• 第 1 步：创建 ERC-4337 智能账户 0xb648，并将其同时指定为外部 UserOperation 的发送者和付款人。
• 第 2 步：同时在旧版和新版 CheckoutPool 中调用 deposit()，在新版 CheckoutPool 中创建一个结算金额为 85,730 USDC 的结账记录。
• 第 3 步：在旧版 CheckoutPool 中调用 bridge()，并使用恶意的 bridgeParams：将 target 设置为 CheckoutPaymaster，并将 callData 编码为携带外部 UserOperation 作为负载的 activateAndCall() 调用。

• 第 4 步：执行路径到达新版 CheckoutPool (0x1929...0215) 的 execute()，后者将 85,730 USDC 转移至作为 ops[0].sender 指定的地址 0xb648。

• 第 5 步：进入 EntryPoint.handleOps()：由于 0xb648 同时扮演发送者和付款人角色，账户验证和付款人验证均在攻击者控制之下，攻击者成功获利 85,730 USDC。

结论

此次事件起因于旧版 CheckoutPool 在 bridge() 路径上缺乏访问控制和数据绑定，损失约 8.57 万美元。为避免类似事件，协议应在敏感路由和结算流中强制执行严格的访问控制，确保外部提供的有效载荷与协议内的记录保持一致，并在补丁升级后及时删除失效合约的特权关系。

4. Keom 事件

简要总结

2026 年 3 月 18 日，Polygon zkEVM 上的 Compound V2 分叉借贷协议 Keom 遭到攻击，损失约 3.5 万美元。根本原因是 redeemUnderlying() 调用的 redeemFresh() 中存在会计逻辑缺陷。程序限制了份额销毁数量，但并未相应更新底层资产的提款金额。这种不一致使得攻击者能够提取出远超其份额应得资产的资金。

背景

Keom 是基于 Compound V2 分叉的借贷协议。用户将 ETH 存入市场并获得 kETH。当用户赎回时，协议使用当前的汇率将 kETH 份额兑换回 ETH。协议内有两个赎回入口：按份额赎回 (redeem()) 和按底层资产金额赎回 (redeemUnderlying())。

漏洞分析

漏洞位于 kETH 市场 (0x4c6e...0403) 的 redeemFresh() 函数中，该函数由 redeemUnderlying() 调用。攻击者可控的 redeemAmountIn 首先被赋值给 redeemAmount，并用于通过当前汇率计算出所需扣除的 redeemTokens。如果 redeemTokens 超过了赎回者的余额，函数会将其上限设置为 accountTokens[redeemer]。然而，在该设置上限后，redeemAmount 并未重新计算，仍然等于原始的 redeemAmountIn。这使得赎回者可以在只销毁一部分份额的情况下，提取出全额的底层资产。

如下代码所示，redeemFresh() 还通过 redeemAllowed() 执行健康检查。在 Compound V2 设计中，redeemAllowed() 会检查 markets[cToken].accountMembership[redeemer]，仅当账户已进入该市场时才调用流动性检查；否则会跳过检查。由于 redeemAmountIn 由攻击者控制且可被设为极大值，若 kETH 仍被计为抵押品，则流动性检查会失败。这意味着，如果不先绕过健康检查，上述会计缺陷本身并不直接具备可利用性。

攻击分析

以下分析基于合约交易 0x4ccde7...03d9dfd8。

• 第 1 步：仅存入 0.001 ETH 调用 mint()，获得极小额的 kETH 余额。

• 第 2 步：调用 exitMarket() 清除账户在 kETH 市场的成员身份，从而使 redeemAllowed() 完全绕过流动性检查（如前文漏洞分析所述）。
• 第 3 步：调用 redeemUnderlying() 提取市场的全部 ETH 余额（约 38.6 ETH），利用会计缺陷耗尽了市场的 ETH。

结论

此次事件由会计漏洞引起，因在限制份额销毁后未重新计算赎回金额而导致约 3.5 万美元的损失。赎回逻辑必须在任何设限或调整后重新计算所有相关数值，以保持“份额-资产”的一致性。Compound V2 分叉协议应仔细审查该路径，因为其他衍生版本中可能也存在类似缺陷。

5. ShiMama 事件

简要总结

2026 年 3 月 18 日，BNB Chain 上的通缩代币协议 ShiMama 遭到攻击，损失约 3.5 万美元。根本原因是 executePairBurn() 函数缺乏访问控制，允许任何用户触发池储备的提取与销毁，从而实现价格操纵。

背景

ShiMama 协议包含一项链上通缩机制，旨在从 AMM 配对池中抽取代币并销毁。该机制在 ShiMama 协议及其代币合约中实现。ShiMama 协议中的 executePairBurn() 函数会根据调用者提供的 referenceIn 参数计算提取金额： pullAmt = referenceIn * pairBurnBpOnSell / 10_000 随后它调用代币合约的 forcePullFromPair()，接着调用 pair.sync() 来销毁提取出的代币。

漏洞分析

根本原因是 ShiMamaProtocol 合约 (0x5049...0b49a) 中的 executePairBurn() 缺乏权限控制。该函数对外部完全开放，任何用户都可触发特权的储备变动和匹配池同步。referenceIn 也由调用者控制，未与任何实际销售额绑定。在 ShiMamaToken.forcePullFromPair() 中，协议可以直接在没有任何限制的情况下将储备金从 Pancake 池中移出，实现任意储备金移除、同步并以此操纵现货价格。

攻击分析

以下分析基于交易 0x13959b...3c20e001。

• 第 1 步：从 Moolah 闪电贷借入 WBNB。
• 第 2 步：将早期交易中预先获取的 30.78e18 ShiMama 存入攻击合约。由于禁止了直接在 Pancake 池购买，攻击者通过在攻击前在 ShiMama 协议中提供和取回流动性来获取代币。
• 第 3 步：调用 executePairBurn() 从 Pancake 池中提取 1,311,349,143.96 枚 ShiMama 并将其销毁，通过降低供应量推高了 ShiMama 价格。
• 第 4 步：攻击者在 PancakeSwap 上以受操纵的高价将 30.78e18 ShiMama 换回 52.98e18 WBNB。
• 第 5 步：偿还闪电贷，剩余 52.98 WBNB 作为净利。

结论

此次事件起因于 executePairBurn() 未设访问限制，暴露了未授权改变流动性池储备的路径。任何修改储备性质的功能在经济上都是敏感的，必须严格限制权限。同时必须将调用者传入的参数与协议计算出的真实数值进行绑定，防止提取储备放大操纵规模。

6. BlindBox 事件

简要总结

2026 年 3 月 19 日，BNB Chain 上的 GameFi 投注协议 BlindBox 遭到攻击，损失约 9.9 万美元。根本原因是随机数强度过弱，导致攻击者能够通过提前预测结果确保 100% 的胜率。此外，getTwapPrice() 依赖可操纵的现货价格而非真实时间加权平均价格，允许攻击者事先拉升池价格，从而进行超过协议原定限额的投注。

背景

BlindBox 允许用户通过将 ATM 代币转入死地址进行投注。协议根据后续区块哈希的奇偶性决定结果。若获胜，BlindBox 将从死地址金库中支付原投注额 1.95 倍的 ATM 奖励。协议使用 getTwapPrice() 来限制单笔投注规模。

漏洞分析

BlindBox 合约 (0x1F83...734c59) 包含两项漏洞：

1. 弱随机数：当结算时间超过 256 个区块时，blockhash(bet.blockNum + 2) 返回零。此时协议回退到从 block.prevrandao、betId 和 block.timestamp 派生的随机数。由于这些输入可以在交易提交前在链下模拟，攻击者仅在计算得出有利结果时才调用 settle()，从而实现确定性的获胜。

2. 可操纵的价格限额：协议通过 getTwapPrice() 约束投注规模，但该函数并未真正实施时间加权平均，而是读取 ATM/USDT 池的现货价格。这使得攻击者可以通过在投注前操纵池价格来绕过限值。

攻击分析

以下步骤展示了攻击模式，第 2 和第 3 步形成了一个配对序列（例如 betId=5,284），攻击者通过多次重复获利。

• 第 1 步：操纵 ATM/USDT 池，拉高 ATM 现货价格，以便 getTwapPrice() 在下一步中允许更大幅度的投注。
• 第 2 步：将膨胀后的 ATM 金额转入死地址，进行大额投注（例如 0x4be049...3af12c）。

• 第 3 步：等待超过 256 个区块，区块哈希归零并激活回退路径。随后攻击者在链下模拟结果，仅在计算结果有利时才调用 settle()（例如 0x68eedc...718ce8）。

结论

此次事件起因于随机数可预测及输入作为 TWAP 价格的现货池易受操纵，损失约 9.9 万美元。协议应取消在区块哈希窗口过期后仍可结算的路径，并将价格源替换为抗波动操纵的方案。

7. Resolv 事件

简要总结

2026 年 3 月 22 日，以太坊稳定币协议 Resolv 曝出基础设施密钥泄露，导致未授权方调用了特权的“交换定稿”逻辑。攻击者利用该特权函数铸造了 8000 多万无抵押 USR。影响不仅局限于铸造事件本身，由此引发的 USR 脱锚还触发了广泛的链上连锁反应。

背景

Resolv 是一种依靠抵押品支持来结算并发行 USR 的协议。其交换完成流水线 completeSwap() -> mint() -> transfer() 直接影响 USR 的流通供应，因而高度依赖授权完整性和抵押完整性。在正常运行下，Resolv 合约 (0xa27a...5861) 中的 completeSwap() 仅在抵押品存入并验证后，才由特权基础设施密钥 (SERVICE_ROLE) 调用。

漏洞分析

该事件属于特权密钥泄露，攻击者调用了受信任的结算逻辑，并在没有等额抵押品流入的情况下触达了 USR 的铸造路径。一旦攻击者获得受信任的签名权限，completeSwap() 路径本身并未在链上执行任何针对铸造的前置约束；抵押品的有效性完全依赖于链下的授权。这次控制平面泄露导致了供应完整性的直接崩盘。

攻击分析

• 第 1 步：在攻击前，攻击者提交了一笔交换请求 0x590b5c...de732c89，为后续恶意的交换定稿做好状态准备。
• 第 2 步：攻击者使用泄露的特权密钥，通过三笔交易调用 completeSwap()，共铸造了超过 80,000,000 USR：0xfe37f2...dc33743、0x41b6b9...db1f18f 以及 0x7f9143...53a931d。

结论

此次事件强调，稳定币的安全性必须依赖于硬性的链上预设条件，而不能仅凭受信任的操作员角色。值得注意的是，该事件的影响远超 8000 万美元的非法铸币。由于 Resolv 资产被广泛用作多个借贷协议的抵押品，其脱锚引发了跨多协议的连锁反应。正如 Chaos Labs 所报道，那些使用自动化收益策略的链上管理员缺乏实时风险控制能力，持续向已受损的市场注入新鲜资本。这最终将一起局部的攻击转化为了一场跨协议的传染事件，导致多个借贷协议蒙受数百万美元的坏账。

关于 BlockSec

BlockSec 是一家全栈区块链安全与加密合规服务商。我们提供构建产品与服务，帮助客户在协议与平台的整个生命周期中进行代码审计（包括智能合约、区块链及钱包）、实时拦截攻击、分析事故、追踪非法资金并满足 AML/CFT 合规要求。

BlockSec 已在权威会议上发表多篇区块链安全论文，报告过多个 DeFi 应用的零日漏洞，拦截过多次黑客攻击并挽救了超 2000 万美元的资产，为数十亿美元的加密资产保驾护航。

• 官网：https://blocksec.com/

• 官方 Twitter：https://twitter.com/BlockSecTeam

• 🔗 BlockSec 审计服务 : 提交审计请求

• 🔗 Phalcon 安全平台: 预约演示

• 🔗 Phalcon 合规服务