Back to Blog

Web3安全事件周报 | 2026年3月23日 – 3月29日

April 2, 2026
20 min read

在过去一周(2026/03/23 - 2026/03/29),BlockSec 检测并分析了八起攻击事件,总估计损失约 153 万美元。下表总结了这些事件,并在后续章节中提供了每起事件的详细分析。

日期 事件 类型 估计损失
2026/03/23 未知事件 1 整型溢出 ~$97K
2026/03/23 未知事件 2 重入 ~$11K
2026/03/23 Cyrus Finance 事件 业务逻辑缺陷 ~$512K
2026/03/23 BCE Token 事件 Token 设计缺陷 ~$679K
2026/03/25 未知事件 3 记账错误 ~$1.2K
2025/03/25 MYX 事件 业务逻辑缺陷 ~$3.6K
2026/03/26 未知事件 4 Token 设计缺陷 ~$133.5K
2026/03/27 EST Token 事件 Token 设计缺陷 &
现价依赖
~$92.3K

Web3 最佳安全审计机构

在上线前验证设计、代码和业务逻辑


1. 未知事件 1

简要概述

2026 年 3 月 23 日,以太坊上一个未经验证的合约因其分配逻辑中的整型溢出漏洞被攻击,估计损失约 97,000 美元。0x317de4f6() 函数在没有溢出保护的情况下累加用户控制的代币数量,导致攻击者只需支付 1 wei 的 USDT 即可通过 claim() 函数触发回绕并提取合约的全部 USDT 余额。

漏洞分析

根本原因是合约 0xF0a105...568C970x317de4f6() 函数的整型溢出。该函数接受一个记录数组(每个记录包含账户和金额),并通过遍历数组将所有金额累加到 totalAmount。由于累加过程中缺少溢出检查,攻击者可以提供精心构造的记录,使其金额回绕 uint256,从而使 totalAmount 任意地变小,而单个分配金额保持不变。

攻击分析

以下分析基于交易 0x73bd1384...630b053

  • 第一步:攻击者从 Uniswap V4 借用了 1 wei 的 USDT 作为攻击的初始资本。

  • 第二步:攻击者查询了受害者合约的 USDT 余额,然后调用 0x317de4f6() 并提供了一个精心构造的数组。其中一个金额设置为接近 uint256 的上限,另一个金额设置为受害者合约的 USDT 余额。它们的总和溢出为 1,允许攻击者仅支付 1 wei USDT 即可记录相当于受害者全部 USDT 余额的分配。

  • 第三步:攻击者调用 claim() 从受害者合约中提取了 97,812e6 USDT

  • 第四步:攻击者偿还了从 Uniswap V4 借用的 1 wei USDT,并将剩余的 USDT 兑换成 WETH,完成了攻击。

结论

此事件突显了在 Solidity 0.8.0 之前的版本中使用未经验证的算术的风险。所有关键的财务计算都应明确使用防溢出算术(例如 SafeMath 或 Solidity >=0.8.x)来防止回绕问题。


开始使用 Phalcon Explorer

深入了解交易,明智行动

立即免费试用

2. 未知事件 2

简要概述

2026 年 3 月 23 日,以太坊上一个未经验证的合约因重入漏洞被攻击,估计损失约 11,000 美元。0xbe16634e() 函数在结算前更新了与流动性相关的记账,并调用了外部回调,但没有任何重入保护。通过在上次调用结算之前反复重入该函数,攻击者夸大了其记录的流动性,随后提取了比实际存入更多的 USDCWETH

漏洞分析

根本原因是合约 0x39Ed37...9C6b080xbe16634e() 函数的重入问题。该函数在结算前更新与流动性相关的状态,包括用户流动性和 tick 储备金,并通过 msg.sender.call() 调用外部回调,而没有任何重入保护。由于余额检查是逐次调用执行的,攻击者可以递归地重入该函数并夸大内部流动性记账,而最深层调用中的一次代币转账就足以满足嵌套执行流程。

攻击分析

以下分析基于交易 0x1382e898...fad993

  • 第一步:攻击者从 Uniswap V4 借用了 100e8 USDC 和 10e18 WETH 作为攻击的初始资本。

  • 第二步:攻击者调用 0xbe16634e() 添加流动性。在执行过程中,受害者合约调用了攻击者的 0x7c65be42() 函数,该函数在上次调用结算之前重入了 0xbe16634e()

  • 第三步:通过反复执行此重入流程,攻击者不断增加其记录的流动性。在最深层调用中,攻击者只转账了一次所需的代币,这足以满足嵌套的余额检查。

  • 第四步:在夸大了记录的流动性之后,攻击者检查了池状态,并将额外的资金转入池中,使其持有足够的 USDCWETH 以满足即将到来的提款。

  • 第五步:攻击者再次调用 0xbe16634e() 以移除流动性,并根据夸大的记账从池中提取了 USDCWETH

  • 第六步:攻击者偿还了 Uniswap V4,将剩余的 USDC 兑换成 WETH,完成了攻击。

结论

此事件表明,在调用未经保护的外部回调时,在结算前更新流动性记账存在危险。为防止类似攻击,协议应严格遵循“检查-效果-交互”模式,并使用重入保护来保护外部回调。


3. Cyrus Finance 事件

简要概述

2026 年 3 月 23 日,BNB Chain 上的一个收益耕作协议 Cyrus Finance 因其依赖池当前现价的流动性移除公式存在缺陷而被攻击,估计损失约 512,000 美元。该协议使用 CYRP NFT 头寸来代表其在 PancakeSwap V3 流动性中的比例份额,但从用户份额到底层流动性的转换会读取 slot0(),这在同一笔交易中是可操纵的。通过闪贷驱动的交易改变价格,攻击者夸大了其 NFT 头寸的流动性价值,并提取了超过其公平份额的金额。

背景

Cyrus Finance 是 BNB Chain 上一个收益耕作协议,它管理 PancakeSwap V3 池中的流动性头寸。用户存入 USDT 以换取 CYRP NFT 头寸,这些头寸代表了用户在协议跨多个 PancakeSwap V3 头寸的流动性份额。用户可以通过 exit() 函数提取本金和奖励。

漏洞分析

漏洞存在于 CyrusTreasury (0xb042Ea...0aE10b) 中的 withdrawUSDTFromAny() 函数。在处理提款时,该函数从 PancakeSwap V3 池的 slot0()(即当前现价)获取 sqrtPriceX96,并将其传递给 getAmountsForLiquidity() 以估算协议的全部头寸流动性当前代表多少 amount0 / amount1

然后,它基于此现价估值计算出 availableUSDT,并使用以下公式确定为满足提款请求应移除多少流动性:

liquidityToUse=liquidityremaining/availableUSDTliquidityToUse = liquidity \cdot remaining / availableUSDT

换句话说,该合约不直接赎回固定的所有权份额。相反,它首先估算头寸的当前 USDT 等价价值,然后将请求的 USDT 金额转换回成比例的流动性金额。

这是不安全的,因为 slot0() 在同一笔交易中是可以操纵的。通过暂时改变池价格,攻击者可以扭曲 availableUSDT,这直接影响了计算出的 liquidityToUse

攻击分析

以下分析基于交易 0x85ac5d15...46d452

  • 第一步:攻击者从 PancakeSwap V3 池发起闪贷,借入了约 1,798 ETH

  • 第二步:攻击者在协议维护流动性的目标池中执行了一笔大额 ETHUSDT 的交易,故意改变了池价格和当前 tick。同时,攻击者通过 safeTransferFrom() 将 CYRP NFT 头寸 #15505 从 0x01737d...6ffa3 转让给了攻击合约。

  • 第三步:攻击者在 CyrusTreasury 上调用了 exit(15505)。在执行过程中,withdrawUSDTFromAny() 读取了 PancakeSwap V3 池的 slot0(),并根据操纵的现价计算出 availableUSDT。由于 tick 被扭曲,协议高估了与 NFT 份额相对应的流动性价值。然后,它调用 decreaseLiquidity()collect(),释放了超过 Cyrus 头寸公平价值的 USDT

  • 第四步:攻击者恢复了池状态,偿还了闪贷,并将剩余利润(约 512,000 美元)转入了 EOA 0xf96EB1...3b63b

结论

缓解措施应将现价 slot0() 定价替换为防操纵的定价(在足够观察窗口内的 TWAP,或 Chainlink 等外部预言机),然后再将其转换为可提取的 USDT


4. BCE Token 事件

简要概述

2026 年 3 月 23 日,BNB Chain 上的 PancakeSwap BCE-USDT 池因 BCE 代币中存在缺陷的销毁机制被攻击,估计损失约 679,000 美元。攻击者部署了两个恶意合约来绕过 BCE 的买卖限制,并触发了针对流动性池储备的代币销毁,操纵了池的价格并耗尽了其 USDT

漏洞分析

漏洞源于 BCE 代币 (0xcdb189...999999) 的缺陷销毁机制。核心问题是,用户影响的状态变量 scheduledDestruction 被用于直接从 PancakeSwap 对地址销毁代币,而不是从用户自己的余额中销毁。在卖出操作期间,合约根据交易量和当前池储备金在 scheduledDestruction 中累积销毁金额。这个值不会从卖家那里扣除。相反,它稍后通过一个单独的代码路径执行,该代码路径销毁对合约的代币并调用 sync()

由于攻击者控制交易量并可以操纵池储备金,他们可以将 scheduledDestruction 设置为任意值,并触发销毁来压缩交易对的 BCE 储备金,从而以有利于自己的方式扭曲池价格。

攻击分析

以下分析基于交易 0x85ac5d15...46d452

  • 第一步:攻击者调用了一个恶意合约 (MC1) 来通过多个闪贷和一个借贷池借入 1.235 亿 USDT

  • 第二步:攻击者部署了第二个恶意合约 (MC2),并将所有借入的 USDT 转入 MC2。

  • 第三步:攻击者(通过 MC2)在 BCE-USDT 池中将 222.2 万 USDT 兑换成 552.9 万 BCE

  • 第四步:攻击者将 552.9 万 BCE 从 MC2 转入 MC1(通过 MC1.drain());由于销毁机制,MC1 收到了 276.4 万 BCE

  • 第五步:攻击者(通过 MC1)将 248.8 万 BCE 兑换成 136.8 万 USDT,根据池储备金和交易金额将 scheduledDestruction 变量更新为约 174K。该变量稍后被用作销毁金额。

  • 第六步:攻击者(通过 MC2)将 3490 万 USDT 兑换成 348.4 万 BCE,进一步将 BCE 储备金压缩到约 174K。

  • 第七步:攻击者将 MC2 中的剩余 BCEUSDT 转入 MC1。由于 scheduledDestruction 大于 0(即约 174K),BCE 的转账触发了销毁,将 BCE 储备金压缩到约 10,000。

  • 第八步:攻击者以操纵的价格将剩余的 BCE 兑换成 USDT

  • 第九步:攻击者偿还了所有贷款,净赚约 679,000 美元。

结论

此事件是由代币经济逻辑中的基本缺陷引起的,其中一个用户影响的状态变量被用来修改流动性池的余额,而不是用户自己的余额。该合约隐含地假设来自交易活动的销毁将反映用户成本,但实际上,它允许攻击者构建一个延迟的销毁,该销毁以 LP 储备金为代价进行结算。因此,攻击者可以用有限的资本敞口操纵池深度和定价,从而从流动性提供者那里提取价值。


5. 未知事件 3

简要概述

2026 年 3 月 25 日,BNB Chain 上一个未经验证的质押合约因跨多种质押模式的记账不一致而被攻击,估计损失约 1.2 千美元。该合约在 stake2()/withdraw2()stake3()/withdraw3() 之间共享相同的头寸变量,尽管这些函数处理的是不同的代币篮子和比例。攻击者通过较轻的 stake2() 模式存入,通过较重的 withdraw3() 模式赎回,反复提取超额代币。

背景

这是一个具有多种质押和提款模式的质押合约。标准的 stake()withdraw() 路径是完整的质押模式,它处理 PangolinBzztBzzone 的代币篮子以及奖励记账逻辑。stake3()withdraw3() 路径使用相同的三个代币篮子和相同的存入/取出比例,但跳过了额外的奖励记账流程。相比之下,stake2()withdraw2() 路径是一种较轻的模式,只处理 PangolinBzzt,因此使用了与另外两种模式不同的代币组合和比例。

漏洞分析

根本原因是合约 0x29d36c...774137 中记账不一致。尽管 stake2()/withdraw2()stake3()/withdraw3() 处理的是不同的代币篮子,但它们都更新了相同的变量 _exit[msg.sender]_totalSupply。因此,通过较轻的 stake2() 模式创建的头寸可以通过较重的 withdraw3() 模式赎回。

实际上,stake2(amount) 只提取 amountPangolinamountBzzt,但 withdraw3(amount) 返回 amountPangolin10 * amountBzzt10 * amountBzzone。这意味着通过 stake2() 质押 20e18 Pangolin 和 20e18 Bzzt 会创建一个 _exit 余额,该余额之后可用于通过 withdraw3() 赎回 20e18 Pangolin、200e18 Bzzt 和 200e18 Bzzone。通过重复这种不匹配,攻击者持续从合约中提取超额代币。

攻击分析

以下分析基于交易 0x7fcd5882...323f8d

  • 第一步:攻击者部署了一个合约,地址为 0x9bce07d8bbe4f19dfe465710ff9612878bfe3302,并为其提供了 0.05 BNB 作为资金。然后,攻击者将资金包装成 WBNB,然后兑换成精确的 20e18 Pangolin、20e18 Bzzt 和 200e18 Bzzone,并批准质押合约花费这些获得的代币。

  • 第二步:攻击者调用 stake2() 并输入 20e18。这会将 20e18 Pangolin 和 20e18 Bzzt 转入质押合约,并将攻击者的共享 _exit 余额增加了 20e18。

  • 第三步:攻击者随后调用 withdraw3() 并输入 20e18。由于 withdraw3() 只检查了共享的 _exit 余额,合约返还了 20e18 Pangolin、200e18 Bzzt 和 200e18 Bzzone,即使该头寸是通过 stake2() 创建的。

  • 第四步:攻击者在同一笔交易中多次重复 stake2() -> withdraw3() 循环。在每一轮中,返还的 Pangolin 和一小部分返还的 Bzzt 被用于下一次 stake2() 调用,而 Bzzone 则被送回质押合约,以便后续的 withdraw3() 调用能够继续成功。通过这种循环,攻击者将其 Bzzt 余额从 20e18 增加到 16,400e18。

  • 第五步:攻击者将获得的代币兑换回 WBNB,将资金解包装成 BNB,然后将约 2.007e18 BNB 转入攻击者 EOA,完成了攻击。

结论

为防止类似攻击,质押合约应隔离每种模式的记账,并确保每个提款路径都与其对应的存款路径完全匹配资产构成和比例。


6. MYX 事件

简要概述

2026 年 3 月 25 日,以太坊上的 MYX Network 的 sMYX 合约被攻击,导致该池损失约 667 万 MYX 代币(约 3.6 千美元利润)。根本原因是转账函数中的供应量记账与 sMYX 合约中的股息分配逻辑之间存在缺陷的交互。通过在受控账户之间反复转账 sMYX,攻击者夸大了每股利润变量,制造了未背书的股息,并提取了比最初存入更多的 MYX

背景

sMYX 合约 (0x404328...d27F66) 遵循股息分配代币模型。用户通过 buy() 函数存入 MYX 代币,并收到代表其份额的 sMYX 份额。股息使用存储在 stor_11 中的全局累加器(每股利润)进行跟踪。每个用户的可领取股息计算方式是其累积利润的比例份额减去其记录的支付基线。该模型在概念上与早期反思型代币相似,其中流入的价值在现有持有者之间重新分配。

漏洞分析

漏洞源于供应量记账和股息分配逻辑之间的缺陷交互。转账函数通过增加基于转账金额除以当前总供应量的全局每股利润变量,不正确地引入了新的股息。此操作没有实际的 MYX 代币流入作为支撑,这意味着股息实际上是内部记账产生的,而不是来自真实的经济活动。同时,由于减法辅助函数的反向语义,该函数减少了记录的总供应量,即使没有代币被实际销毁。

结果是,每次后续转账都会导致每股利润值增加,因为相同的转账金额被除以越来越小的总供应量。

攻击分析

以下分析基于交易 0x843c9ea7...a55b90

  • 第一步:攻击者通过闪贷启动了资本,并将其转换为 MYX,然后存入 sMYX 合约,以获得在股息系统中的主导份额,从而确保对未来大部分奖励分配的控制。

  • 第二步:攻击者将他们的头寸拆分到两个受控合约中,并启动了一个协调循环,在股息实现和状态操纵之间交替进行,从而能够反复遍历易受攻击的记账路径。

  • 第三步:通过在受控账户之间反复转账,攻击者人为地夸大了协议的每股利润变量,同时减少了记录的总供应量,制造了未背书的股息,并放大了其分配率。

  • 第四步:在每次操纵循环后不断提取,攻击者提取了这些虚构奖励的大部分,有效地从协议中耗尽了 MYX 储备金,而没有引入新资本。

  • 第五步:攻击者退出了所有头寸,将提取的 MYX 兑换回 WETH,偿还了闪贷,并保留了剩余余额作为利润。

结论

此事件不仅仅是庞氏经济设计的后果,而是股息记账实施中的一个关键缺陷。为减轻此类漏洞,转账操作不得影响总供应量或触发股息分配,并且每股利润更新只能在引入真实资产时发生。


7. 未知事件 4

简要概述

2026 年 3 月 26 日,一个带有推荐奖励的 TUR 质押合约在 BNB Chain 上被攻击,估计损失约 133,500 美元。Stake 合约使用实时的 AMM 现价来计算存款价值,这些现价在单笔交易内是可操纵的。攻击者使用闪贷抬高了 TUR 的价格,在价格被抬高的窗口期内进行质押,并通过自行控制的推荐人账户提取了超出预期的 TUR 奖励。

背景

Stake 合约 (0x03D809...415Abe) 是一个带有推荐奖励的 TUR 质押合约。用户首先通过 bind() 绑定一个上线,然后调用 stake(),该函数会销毁质押的 TUR(将其发送到 0xdead)并根据用户的内部 power(决定用户稍后可以提取多少 TUR 奖励的权重)进行记账。

power 不是按固定比例分配的。相反,getPowerAmount() 通过链接两个实时 AMM 价格:TUR/NOBELNOBEL/USDT,将存入的 TUR 转换为以 USDT 计价的价值,这两个价格均从当前交易对储备金中读取。该合约还通过 _distributeRefPower() 向一级和二级推荐人提供额外 power 奖励。

漏洞分析

根本原因是 Stake 合约中不安全的现价依赖。每次存款时,stake() 都计算 uValue = getPowerAmount(amount),将其转换为 _power = _uValue * 100,更新质押者的记账,然后调用 _distributeRefPower() 将额外的 power 传播给上游推荐人。

具体来说,uValue 计算如下:

uValue=getPowerAmount(amount)uValue = getPowerAmount(amount)

其中 getPowerAmount() 实际上是:

amount×TUR/NOBEL 现价×NOBEL/USDT 现价amount \times \text{TUR/NOBEL 现价} \times \text{NOBEL/USDT 现价}

实现通过 getReserves() 直接从当前交易对储备金读取这些价格,因此质押估值完全依赖于同一交易中的现价,而不是防操纵的预言机或 TWAP。

这允许攻击者暂时抬高 TUR 的链上估值,在操纵窗口期内进行质押,并获得夸大的 uValuepower。推荐逻辑放大了损害:_distributeRefPower() 向第一推荐人授予质押者 power 的 20%,向第二推荐人授予 5%,但这些额外分配并未相应更新这些推荐人的 rewardDebt。结果是,由攻击者控制的推荐人账户可以立即从 Stake 合约中提取不成比例的 TUR 奖励。

攻击分析

以下分析基于交易 0x96c9ce3c...81e348

  • 第一步:攻击者通过 ListaDAO 的 Moolah 合约借入了 1,900,000e18 USDT 作为闪贷资本。

  • 第二步:攻击者利用借来的资本操纵了 NOBEL-USDTTUR-NOBEL 池,暂时将 TUR 的现价估值大幅推高。

  • 第三步:在操纵窗口期内,攻击者将 7,770,707e18 TUR 质押到 Stake 合约中。交易发出 StakeEvent,显示一个被极度夸大的 uValue(8,283,864e18)和相应的 power(828,386,488e18)。

  • 第四步:由于攻击者已经安排了自行控制的推荐人账户,_distributeRefPower() 从被操纵的质押中获得了额外的奖励 power。第一和第二推荐人获得了预期的 20% 和 5% 推荐分配。

  • 第五步:增强的推荐人账户随后从 Stake 合约中提取了 TUR 奖励。在同一笔交易中,Stake 将 15,238,941e18 TUR 转入 0xFd11...AcEaB,将 3,809,924e18 TUR 转入 0x9007...E550B;这两个地址立即将相同的金额转给攻击者。4:1 的支付比例与合约的 20% 对 5% 的推荐 power 分配相符。

  • 第六步:交易还显示了从 Stake 到资金钱包 0xb302...89923 的索赔费用流,这与 claim() 实现向领取者发送奖励前收取 3% TUR 费用的情况一致。

  • 第七步:在提取了放大的 TUR 奖励后,攻击者将收益兑换回 USDT,偿还了 1,900,000 USDT 的闪贷,并将 133,490e18 USDT 转入 0xEf67...4e5898 作为利润。

结论

此事件是由 Stake 合约中易受操纵的奖励估值模型引起的,而不是 TUR 代币独立的 LP 股息记账。通过将质押 power 和推荐奖励与实时 AMM 储备金比例挂钩,该合约允许闪贷驱动的攻击者抬高 TUR 的现价,制造过度的奖励 power,并通过自行控制的推荐人账户从质押合约中提取 TUR。更安全的设计应将现价储备金定价替换为防操纵的预言机或足够长的 TWAP,并确保任何推荐 power 的增加都伴随着一致的奖励债务记账。


8. EST Token 事件

简要概述

2026 年 3 月 27 日,BNB Chain 上的 BNBDeposit 合约因两个问题被攻击,估计损失约 92,300 美元:BNBDeposit 中的现价依赖性以及 EST 代币中的缺陷销毁机制。价格依赖性允许攻击者收购大量 EST,而缺陷销毁机制允许攻击者通过类似三明治的操纵耗尽 EST-WBNB 池。

漏洞分析

事件的根本原因是双重的:

  1. BNBDeposit 合约 (0xE71547...d29A61) 中的 onTokenReceived() 函数根据合约余额和 EST 的现价计算用户的可领取金额,这两者都容易被操纵。

  2. EST 代币 (0xD4524B...498a91) 实现了一个缺陷的销毁机制,允许攻击者通过直接将 EST 转账到池中来销毁 EST-WBNB 池中的 EST

结果是,攻击者利用了这两种漏洞执行了三明治攻击,并从 EST-WBNB 池中窃取了 WBNB

攻击分析

以下分析基于交易 0x2f1c33ea...bd1626

  • 第一步:攻击者通过 Moolah 借入了 250,000e18 WBNB,并解除了 15e18 WBNB 的包装以获取 BNB 用于攻击。

  • 第二步:攻击者重复将 0.3e18 BNB 转账到 BNBDeposit 34 次(总计 10.2e18 BNB)。每次直接转账都触发了存款逻辑。在此步骤中,攻击者获得了约 9,100e18 LP 代币(以虚拟记账计算)和 2.65e18 WBNB 作为奖励。

  • 第三步:攻击者将 400e18 WBNB 兑换成约 822Me18 EST,并将 BNBDeposit 指定为接收方,从而抬高了 BNBDepositEST 余额和池中的 EST 价格。

  • 第四步:攻击者将 1e18 EST 转入 BNBDeposit 以触发领取机制,根据放大的价格和余额获得了 20Me18 EST

  • 第五步:攻击者将 245,000e18 WBNB 兑换成约 330Me18 EST,并将 BNBDeposit 指定为接收方。

  • 第六步:攻击者执行了约 150 次转账-套利操作,以持续销毁 EST-WBNB 池中的 EST

  • 第七步:攻击者将剩余的 EST 兑换成 245,560e18 WBNB

  • 第八步:攻击者偿还了闪贷,净利润为 150 WBNB

结论

此事件是由现价依赖性和有缺陷的销毁机制这两个问题造成的。为减轻类似风险,项目必须在部署前确保可靠的价格预言机和健全的代币销毁逻辑。


开始使用 Phalcon Security

检测所有威胁,警报关键事件,阻止攻击。

立即免费试用

关于 BlockSec

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

BlockSec 已在著名会议上发表了多篇区块链安全论文,报告了多个 DeFi 应用的零日攻击,阻止了多次黑客攻击挽回了超过 2000 万美元,并保护了数十亿美元的加密货币。

Sign up for the latest updates
The Decentralization Dilemma: Cascading Risk and Emergency Power in the KelpDAO Crisis
Security Insights

The Decentralization Dilemma: Cascading Risk and Emergency Power in the KelpDAO Crisis

This BlockSec deep-dive analyzes the KelpDAO $290M rsETH cross-chain bridge exploit (April 18, 2026), attributed to the Lazarus Group, tracing a causal chain across three layers: how a single-point DVN dependency enabled the attack, how DeFi composability cascaded the damage through Aave V3 lending markets to freeze WETH liquidity exceeding $6.7B across Ethereum, Arbitrum, Base, Mantle, and Linea, and how the crisis forced decentralized governance to exercise centralized emergency powers. The article examines three parameters that shaped the cascade's severity (LTV, pool depth, and cross-chain deployment count) and provides an exclusive technical breakdown of Arbitrum Security Council's forced state transition, an atomic contract upgrade that moved 30,766 ETH without the holder's signature.

Weekly Web3 Security Incident Roundup | Apr 13 – Apr 19, 2026
Security Insights

Weekly Web3 Security Incident Roundup | Apr 13 – Apr 19, 2026

This BlockSec weekly security report covers four attack incidents detected between April 13 and April 19, 2026, across multiple chains such as Ethereum, Unichain, Arbitrum, and NEAR, with total estimated losses of approximately $310M. The highlighted incident is the $290M KelpDAO rsETH bridge exploit, where an attacker poisoned the RPC infrastructure of the sole LayerZero DVN to fabricate a cross-chain message, triggering a cascading WETH freeze across five chains and an Arbitrum Security Council forced state transition that raises questions about the actual trust boundaries of decentralized systems. Other incidents include a $242K MMR proof forgery on Hyperbridge, a $1.5M signed integer abuse on Dango, and an $18.4M circular swap path exploit on Rhea Finance's Burrowland protocol.

Weekly Web3 Security Incident Roundup | Apr 6 – Apr 12, 2026
Security Insights

Weekly Web3 Security Incident Roundup | Apr 6 – Apr 12, 2026

This BlockSec weekly security report covers four DeFi attack incidents detected between April 6 and April 12, 2026, across Linea, BNB Chain, Arbitrum, Optimism, Avalanche, and Base, with total estimated losses of approximately $928.6K. Notable incidents include a $517K approval-related exploit where a user mistakenly approved a permissionless SquidMulticall contract enabling arbitrary external calls, a $193K business logic flaw in the HB token's reward-settlement logic that allowed direct AMM reserve manipulation, a $165.6K exploit in Denaria's perpetual DEX caused by a rounding asymmetry compounded with an unsafe cast, and a $53K access control issue in XBITVault caused by an initialization-dependent check that failed open. The report provides detailed vulnerability analysis and attack transaction breakdowns for each incident.