Web3安全周报 | 2026年3月9日 – 3月15日

在过去的一周（2026/03/09 - 2026/03/15）中，BlockSec 检测并分析了八起攻击事件，估计总损失约为 $1.66M。下表总结了这些事件，详细的案例分析见后续小节。

日期	事件	类型	预估损失
2026/03/09	EtherFreakers 事件	业务逻辑漏洞	~$25K
2026/03/10	Alkemi 事件	业务逻辑漏洞	~$89K
2026/03/10	MT 事件	业务逻辑漏洞	~$242K
2026/03/11	AAVE 清算事件	配置错误	~$1.01M
2026/03/11	Planet Finance 事件	业务逻辑漏洞	~$10K
2026/03/12	AM 事件	业务逻辑漏洞	~$131K
2026/03/12	DBXen 事件	业务逻辑漏洞	~$149K
2026/03/15	Goose Finance 事件	业务逻辑漏洞	~$8K

EtherFreakers 事件

简要总结

2026年3月9日，以太坊上的 NFT 游戏 EtherFreakers 因重复计数出错遭到攻击，导致约 $25K 的损失。游戏中的每个 NFT 都持有一个可提取的 ETH 余额（称为“能量”）。作为一种游戏机制，玩家可以使用 attack() 让一个 NFT 捕获另一个 NFT 并获取目标的能量。然而，合约在支付目标余额后才转移 NFT，且在会计结算前完成转移。转账钩子（hook）随后读取了过期的预支付数据，并将部分数据输入到全局分红池中，从而在没有新增 ETH 支持的情况下膨胀了分红池。攻击者循环利用此捕获机制来拉高全局指数，随后从一批 NFT 中抽走了膨胀后的余额。

背景

EtherFreakers 是一款链上 NFT 游戏，每个 NFT（称为“Freaker”）持有一个可提取的 ETH 余额（能量）。该系统类似于分红池：当发生特定操作时，一小部分 ETH 会按比例分配给所有 Freaker。每个 Freaker 可领取的 ETH 通过全局累计器 freakerIndex 加上每个代币的份额权重 fortune 来追踪。

具体而言，会计公式为：energyOf = basic + (freakerIndex - index) * fortune。当 _dissipateEnergyIntoPool(amount) 运行时，freakerIndex 会增加，将 amount 的 80% 分配给所有 Freaker，20% 分配给创建者。通过 charge() 直接存入只会增加 basic 而不影响 freakerIndex。因此，freakerIndex 的增长必须始终有进入系统的真实以太币作为支撑。如果 freakerIndex 在没有相应 ETH 流入的情况下增长，Freaker 提取的以太币将会超过合约实际持有的金额。

漏洞分析

根本原因是 EtherFreak 合约（0x3A27...c0f33）中错误的执行顺序。当捕获成功时，attack() 函数按顺序执行以下操作：

第 237 行：将 targetCharge（目标 NFT 的全部能量）作为直接 ETH 转账支付给防守方。此时能量已被消耗。
第 240 行：调用 _transfer(defender, capturer, targetId) 移动 NFT。在内部，_transfer() 会调用 ERC-721 钩子 _beforeTokenTransfer()，该函数会通过 energyOf(targetId) 的 0.1% 调用 _dissipateEnergyIntoPool()。这是对 _dissipateEnergyIntoPool() 的第一次调用，它读取的是过期数据，因为第 5 步尚未发生。
第 241 行：显式调用 _dissipateEnergyIntoPool(sourceSpent)。这是第二次调用，属于正常游戏逻辑。
第 244-251 行：更新 sourceId 和 targetId 的 energyBalances。

漏洞在于第 2 步：由于 energyBalances[targetId] 尚未更新，钩子读取的是支付前的余额，并将部分已消耗的能量输入到分红池中。第 1 步的直接 ETH 支付和第 2 步的池输入都提取自同一份能量，导致 freakerIndex 在没有新 ETH 支持的情况下膨胀。

只要调用 _dissipateEnergyIntoPool()，freakerIndex 就会增长：

攻击分析

以下分析基于交易 0x89e24d...9abd2942。

第 1 步：借入 1,700 个 WETH。
第 2 步：在攻击者控制的地址下铸造两个全新的 Freaker（代币 590 和 591）。
第 3 步：反复调用游戏的 attack(590, 591) 函数，并保持执行成功的捕获分支。
第 4 步：每次成功后，将代币 591 转回助手地址，以便重复使用同一对代币。
第 5 步：每次成功的循环都会使 freakerIndex 膨胀到超越系统实际持有的以太币总量。
第 6 步：一旦指数足够高，便释放一批之前受控的 Freaker。代币 ID 496 到 520 每个释放出 0.278052246002402082 个以太币。
第 7 步：将抽取的以太币封装为 WETH，偿还 1,700 个 WETH 的闪电贷，并保留约 7.498 个 WETH 作为利润。

结论

根本原因是 attack() 成功的捕获流程：EtherFreakers 在结算目标代币能量状态之前就支付了 targetCharge。随后 _transfer() 触发了 _beforeTokenTransfer()，该钩子读取了过期的预支付 energyOf(targetId) 并将其部分分散到池中。这在没有新以太币注入的情况下增加了 freakerIndex，导致同一目标能量被同时算作支付和池输入。这是一个业务逻辑膨胀漏洞，而非重入漏洞。

为降低未来类似风险：

在同一笔交易尚未结算时，避免在转账钩子中根据可变状态重新计算经济价值。
如果转账钩子读取状态变量，请确保执行顺序不会影响结果（例如，在钩子运行前结算状态，而不是在之后）。

Alkemi 事件

简要总结

2026年3月10日，以太坊上的 Alkemi 协议遭到攻击，导致约 $89K 的损失。根本原因是会计错误和业务逻辑缺陷。存在缺陷的清算逻辑允许任何人通过同笔交易清算自己的头寸并从中获利。此外，会计错误导致清算过程中攻击者自身抵押品的扣除操作被覆盖，使得攻击者在无需承担预期成本的情况下获得清算奖励。

背景

Alkemi 是一个借贷协议。当借款人的头寸抵押率不足时，任何人都可以调用 liquidateBorrow() 来偿还部分债务并以折扣价扣押抵押品。为防止过度清算，协议将每笔交易的可偿还金额上限设为以下三个值中的最小值：

借款人当前的借款余额（currentBorrowBalance_TargetUnderwaterAsset）。
应用清算折扣后，借款人抵押品所能覆盖的最大还款额（calculateDiscountedBorrowDenominatedCollateral()）。
为了使账户回到清算边界所需的还款额（calculateDiscountedRepayToEvenAmount()），仅在市场 isSupported 时检查。

漏洞分析

根本原因是 Alkemi 协议（0x4822...a888）中的业务逻辑缺陷和会计错误。由于只要借款人有未偿债务，currentBorrowBalance_TargetUnderwaterAsset 就必然大于 0，且只要借款人有抵押品，calculateDiscountedBorrowDenominatedCollateral() 的返回值也必然大于 0，因此 AlkemiEarnPublic 协议实际上依赖 calculateDiscountedRepayToEvenAmount() 来判断给定贷款是否可以清算。在此函数中，应清算的债务金额应基于名为 accountShortfall_TargetUser 的变量计算。

然而在实际实现中，该函数却使用全局变量 closeFactorMantissa 来计算允许偿还的债务上限。结果导致攻击者能够在同一笔交易中借入资金并立即清算自己的头寸。

此外，在 liquidateBorrow() 函数中，当清算人和借款人为同一地址时，变量 supplyBalance_TargetCollateralAsset 和 supplyBalance_LiquidatorCollateralAsset 指向同一存储槽。该函数随后基于相同的初始余额分别计算“减少后的余额”和“奖励后的余额”，并依次写回同一存储槽。由于减少后的余额先被写入，而奖励后的余额在后，减少效果被覆盖且丢失，仅留下了奖励结果。这使得攻击者进一步放大了收益。

攻击分析

以下分析基于交易 0xa170...6d9d。

第 1 步：攻击者从 Balancer 闪电贷借入 51e18 WETH。
第 2 步：攻击者将 51e18 WETH 解封装为 ETH 并存入 Alkemi 协议。
第 3 步：从 Alkemi 借入 39.5e18 ETH。
第 4 步：使用 39.5395e18 ETH 清算自己的头寸。
第 5 步：从 Alkemi 取出 93.5e18 ETH。
第 6 步：偿还闪电贷，净赚 43.4e18 ETH。

结论

根本原因是存在缺陷的清算逻辑允许攻击者在同一笔交易中借入并清算自身头寸以获利，而不正确的会计逻辑进一步放大了攻击者的收益。

为降低未来类似风险：

对于借款人和清算人的余额更新，协议应直接操作存储变量，而不是将余额复制到临时内存变量中进行独立计算和回写。

MT 事件

简要总结

2026年3月10日，BNB Chain 上的通缩代币 MT Token 遭到攻击，损失约 $242K。根本原因是交易限制逻辑缺陷叠加了对特殊转账条件的不一致处理。在通缩阶段，合约在池储备超过固定阈值时会限制买入操作。然而，合约将特定精确金额（如 2e17 MT）的转账视为推荐绑定行为，允许攻击者绕过买入限制并获取初始代币。此外，限制逻辑依赖于不完整的路径检测（isBuy），未能涵盖如 Pair 到 Router 等间接交换路径，且白名单检查进一步缩短了关键验证流程。攻击者在未触发限制或手续费的情况下积累了 MT 代币，利用受控的流动性操作和交易操纵了 pendingBurnAmount，并强迫资金池进入价格被人为抬高的异常状态。

背景

MT Token 是 BNB Chain 上具有内置交易限制的通缩币。在通缩阶段，当池中 MT 储备超过 21,000e18 时，合约会阻止买入操作。一旦储备低于此阈值，通缩阶段结束，重新启用买入。MT Token 还包含推荐机制：精确转账 2e17 MT 或 1e17 MT 会被视为推荐绑定动作而非正常交易。

漏洞分析

根本原因是 MT 合约（0x037E...b449）中设计有缺陷的买入限制。正常情况下，攻击者在受限阶段应无法获取 MT 作为种子资本。然而，合约将精确转账 2e17 MT 视为推荐绑定操作而非买入，从而绕过了买入限制。

此外，交易限制依赖 isBuy 分支来阻止购买，但它并未覆盖“Pair 到 Router”路径。由于 Router 和 Pair 都是白名单地址，此类转账在白名单检查时直接短路，从未触发买入限制逻辑，攻击者通过将买入操作路由给 Router，随后移除流动性将代币提取回个人手中，从而获取 MT。

攻击分析

以下分析基于交易 0xfb57...fca6。

第 1 步：攻击者闪电贷借入 ~358,681e18 WBNB。
第 2 步：攻击者购买 2e17 MT，成功绕过买入限制。
第 3 步：向 Pair 提供 4e12 WBNB 和 2e17 MT 以增加流动性。该转账因上述相同原因绕过了扣费逻辑。
第 4 步：从 Pair 购买 ~10,000,000e18 MT 到 Router，绕过了买入限制和扣费逻辑。
第 5 步：移除一半流动性头寸，提取存放在 Router 中的所有 MT 代币，然后将取回的 MT 卖出换取 WBNB。此步骤中，pendingBurnAmount 被操纵至约 9,000,000e18。
第 6 步：再次购买 ~10,000,000e18 MT，将池中的 MT 储备降至 ~6,756,516e18，低于 pendingBurnAmount。
第 7 步：移除剩余的一半流动性，取回购买的 MT 代币，并调用 distributeDailyRewards() 从池中销毁 MT。最终池中的 MT 储备减少至 21,000e18。
第 8 步：将所有 MT 换回约 1,198e18 WBNB，偿还闪电贷并完成获利。

结论

该漏洞由不正确的交易限制引发，攻击者通过购买特定金额的 BINDING_AMOUNT MT 代币绕过了买入禁令。获取 MT 后，通过添加流动性、购买 MT 进入 Router，最后移除流动性的方式，攻击者避开了费用收取逻辑和买入限制。随后通过卖出操作积累 pendingBurnAmount 并执行销毁，将池储备推向异常状态，从而以高价卖出 MT 获利。

为降低未来类似风险：

在转账语义和交易逻辑之间强制实施严格的分隔。

AAVE 清算事件

简要总结

2026年3月11日，AAVE 在以太坊上发生价值 2100 万美元的不正确清算，导致约 $1.01M 的损失。根本原因是 wstETH 的预言机价格异常，导致原本健康的头寸被判定为抵押率不足，从而被误清算。

背景

AAVE 使用预言机适配器来为包装资产（如 wstETH）定价。上限价格预言机（CAPO）通过将基础 ETH/USD 价格乘以换算比例（getRatio()，即一个 wstETH 值多少 ETH）来推导 wstETH 的价格。为了防止比例操纵，CAPO 应用了基于快照的增长上限： maxRatio = snapshotRatio + maxGrowthPerSecond x (currentTime - snapshotTimestamp) 并在定价时对 getRatio() 的输出进行钳制（clamp）。该机制有效限制了比例及其结果价格的上行漂移。

漏洞分析

根本原因是 CAPO 预言机锚点配置中的时间-比例不匹配（0xe1D9...61Ef）：设置了快照时间戳和快照比例，但快照比例被配置得低于真实的 wstETH/ETH 比例。导致适配器计算出的 maxRatio 低于实时比例，强行向下钳制了 getRatio()，系统性地调低了 wstETH/USD 的预言机价格。抵押品估值的降低削弱了使用 wstETH 作为抵押品的头寸的健康因子，导致原本健康的账户被错误地归类为不健康并被清算。

攻击分析

以下分析基于交易 0x9064...8a9c。

第 1 步：清算人闪电贷借入 ~6304e18 WETH 并清算了借款人头寸。
第 2 步：偿还闪电贷并完成清算。

结论

此次清算是由预言机价格配置错误触发的，使得本应保持健康的借款人被推入违约状态。

为降低未来类似风险：

确保关键参数在每次更新前都经过正确性验证。
在实现中添加校验逻辑以拒绝错误的参数，防止错误的配置被成功应用。

Planet Finance 事件

简要总结

2026年3月11日，Planet Finance 在 BNB Chain 上遭到攻击，估计损失约 $10K。根本原因是协议错误地将借款人已记录的借款余额增加视为计息，允许攻击者通过反复借入并触发抵押折扣结算来掩盖其实际债务。

背景

Planet Finance 是一个借贷协议，允许借款人以一定的利息折扣进行还款。折扣分级，由用户质押的 GAMMA 与其他资产的质押价值比例决定：比例越高，还款折扣越大。折扣计划分为三级，从 0% 到 50%。

漏洞分析

根本原因是当协议（0x4c9E...F467）在 changeUserBorrowDiscount() 中结算借款人的折扣时，错误地将记录借款余额的增加视为新增的应计利息。结果，原本仅适用于应计利息的折扣被错误地应用到了新增的主体贷款上，不当地降低了借款人的债务记录。攻击者通过反复循环“借款”再调用“更新折扣”，积累了过高的折扣，使链上记录的负债始终低于真实借款额，从而获利。

攻击分析

以下分析基于交易 0x5f45...5ec9。

第 1 步：闪电贷借入 200,000e18 USDT。
第 2 步：使用 5,000e18 USDT 购买 WBNB，再以 WBNB 购买约 8,726,524e18 GAMMA。
第 3 步：将所有 GAMMA 质押到 gGAMMA 市场，再存入剩余的 USDT 作为抵押品，将还款折扣增加到 5%。
第 4 步：循环调用 borrow 和 updateUserDiscount 以持续减少债务记录。
第 5 步：偿还债务，赎回抵押品并锁定利润。

结论

此次事件由 changeUserBorrowDiscount() 中的折扣结算逻辑缺陷导致，因将借款额增加误判为新增利息，攻击者从而可以通过反复调用接口下压负债额度获利。

为降低未来类似风险：

在借贷协议中严格区分利息与新增借款。

AM 事件

简要总结

2026年3月12日，BNB Chain 上的通缩代币 AM Token 遭到攻击，损失约 $131K。AM Token 实现了一种 deflationary 机制，每次卖出都会触发从流动性池中的额外销毁。然而，该销毁并非立即执行，而是记录为 toBurnAmount，实际销毁延迟到下一次卖出时触发。这种延时创造了一个窗口期，攻击者可以在此期间买入 AM 以压缩池中的 AM 储备导致其低于 toBurnAmount。当下一次卖出触发延迟销毁时，池中剩余的全部 AM 储备被清空，将价格驱动到极端水平，攻击者借机将赚取的 AM 卖出获利。

背景

AM Token 是 BNB Chain 上的通缩币。每次卖出时，合约将涉及交换的 AM 数量记录为 toBurnAmount，并在下次卖出时销毁该数量的代币。实质上，卖出触发了缩减池内 AM 储备的延迟销毁。此外，在销毁前，协议会将累积的 totalTokenFee 交换为 USDT 并根据费用分配逻辑进行分发。

漏洞分析

根本原因是代币（0x27f9...213f）的卖出逻辑将完整交换的 AM 金额累积为 toBurnAmount，且仅在下次卖出时通过从 AM/USDT 配对中移除代币并调用 pair.sync() 来执行销毁。这种设计允许攻击者操纵储备并进行价格套利。

攻击分析

以下分析基于交易 0xd0d1...f859。

第 1 步：闪电贷借入 ~27,265,119e18 USDC 和 ~361,710e18 WBNB，随后换为约 100,423,811e18 USDT。
第 2 步：卖出 ~5,062e18 AM 换取 USDT，使合约记录的 toBurnAmount 变为 ~4,303e18。
第 3 步：交换 USDT 为回购 AM，将池中储备压缩至 ~4,303e18。
第 4 步：转账 6 wei AM 给池子，触发卖出销毁逻辑。合约将池内全部 AM 销毁至 0。在销毁前，协议尝试先将产生的费用换取 USDT，因此时储备已为空，交换失败。由于包裹在 try/catch 中，回滚被避免，执行继续。
第 5 步：调用 pool.sync()，向池中存入剩余的 USDT 和 1 wei AM。由于同时存入，合约视为增加流动性，toBurnAmount 未累积。 reserve 更新为 7。
第 6 步：卖出剩余 AM 换取 USDT。卖出触发销毁，储备降至 1。因费用累加器之前已被重置，不再执行费用交换，攻击者以极端人为价格卖出获利。
第 7 步：偿还闪电贷获利。

结论

漏洞源于有缺陷的销毁机制在 sell 路径上积累应销毁余额并调用 sync() 时未做总量限制，攻击者借此压缩配对资产价值并进行恶意卖出。

为降低未来类似风险：

每笔交易应限制最大销毁额并实施速率限制。

DBXen 事件

简要总结

2026年3月12日，Burn-to-Earn 协议 DBXen 在以太坊和 BNB Chain 上遭到攻击，损失约 $149K。根本原因是 _msgSender() 和 msg.sender 的不一致。当 burnBatch() 通过 forwarder 调用时，销毁的 XEN 金额被记录在 _msgSender()（攻击者控制）下，但周期记录更新在 msg.sender（即 forwarder）身上。这种分裂允许攻击者针对过期的周期记录领取奖励和费用，造成超额支付。

背景

DBXen 是一个销毁即挖矿的协议。用户通过燃烧 XEN 获取 DXN 奖励及累积的手续费分红。核心机制按“周期”运作。用户调用 burnBatch() 时，(1) 将燃烧的 XEN 记录在调用者地址下；(2) XEN 合约回调 onTokenBurned()，将调用者的燃烧周期记录同步到当前周期。

奖励和费用结算依赖 updateStats()。奖励按用户在该燃烧周期内的占比发放，费用基于上次记录周期至今的累积额计算。两者均依赖周期记录的时效性。

漏洞分析

根本原因是 DBXen 协议（0xf5c8...2abd）中业务逻辑的缺陷。_msgSender() 函数检查 msg.sender 是否为 forwarder，若是则返回 calldata 后 20 字节。而该值可在 forwarder 上下文中被攻击者任意控制。但 burnBatch() 直接销毁 msg.sender 手中的 XEN。因此，攻击者通过转发器调用 burnBatch()，导致协议烧毁了转发器的 XEN 并更新了转发器的周期记录，却将销毁的数量计入 _msgSender() 指定的攻击者地址下。

此后，攻击者调用 claimFees()，updateStats() 计算奖励时，因为 _msgSender() 地址的记录停留在 0，协议会按整个协议历史累积进行清算计算，导致攻击者获得超额收益。

攻击分析

以下分析基于交易 0x914a5a...b808bc37。

第 1 步：注册 Forwarder 合约域分隔符。
第 2 步：将 0.14e18 ETH 换为大量 XEN。
第 3 步：将其转入 Forwarder 合约。
第 4 步：通过 Forwarder 授权 DBXen 消耗这笔 XEN。
第 5 步：调用 DBXen.burnBatch()，将销毁量记录在攻击者地址，并将周期记录同步到转发器。
第 6-7 步：通过转发器分别调用 claimFees 和 claimRewards，将整段历史报酬榨取一空。

结论

DBXen 的账户记录在 forwarder 场景下逻辑分裂，允许攻击者欺骗会计更新机制从而获利。

为降低未来类似风险：

全局统一使用 _msgSender()，确保逻辑与物理地址检查一致。

Goose Finance 事件

简要总结

2026年3月15日，Goose Finance 遭到攻击，损失约 $8K。根本原因是 StrategyGooseEgg 中的份额定价顺序漏洞：deposit() 在结算收获的奖励前铸造份额，导致分母偏小。后续 withdraw() 触发 Harvest 后资产价值上升，攻击者通过循环存取反复赚取差价。

背景

Goose Finance 的资金流向是从 Vault 进入 Strategy，再质押入 MasterChef 赚取 EGG。核心逻辑漏洞是份额定价（Denominator）计算时未包含已产生的 Idle 奖励。

漏洞分析

根本原因是 StrategyGooseEgg（0x0980...b26b）中 Harvest 与份额定价逻辑的解耦。定价依赖 wantLockedTotal 作为分母，但 deposit() 提前 mint 了份额，导致分母未计入 Idle 资产，使得新存款铸造了更多份额。而 withdraw() harvest 回来的资产未完整纳入分母更新，进一步宽了此偏差。