Web3安全事件周报 | 2026年4月13日 – 4月19日

核心见解：

• 2026 年 4 月 13 日至 4 月 19 日期间，在以太坊、Unichain、Arbitrum 和 NEAR 等多个链上检测到四起攻击事件，总计估计损失约 3.1 亿美元。
• 攻击向量包括针对 LayerZero DVN 的 RPC 基础设施投毒、MMR 证明伪造、保险基金中的整数溢出滥用以及保证金交易协议中的循环兑换路径利用。
• KelpDAO 事件（2.9 亿美元）表明，桥梁安全不仅限于智能合约，还延伸到链下验证基础设施。跨越五条链的 WETH 冻结连锁反应以及 Arbitrum 的强制状态转换，进一步揭示了可组合性如何放大单点故障，以及“去中心化”系统的实际信任边界在哪里。

预计阅读时间： 18 分钟

在过去一周（2026/04/13 - 2026/04/19），BlockSec 检测并分析了四起攻击事件，总计估计损失约 3.1 亿美元。下表总结了这些事件，并在后续子章节中提供了每个案例的详细分析。

本周亮点：KelpDAO

此事件因其新颖的基础设施级别攻击向量（针对唯一 DVN 的 RPC 投毒而非智能合约利用）、通过 DeFi 可组合性跨链级联影响以及 Arbitrum 为追回被盗资金强制进行状态转换而引发的治理问题而受到关注。

2026 年 4 月 18 日，KelpDAO 的 rsETH LayerZero OFT 桥被利用，损失约 2.9 亿美元，此次攻击被归因于一个国家支持的演员，很可能是朝鲜的拉撒路集团 [1]。根本原因是 KelpDAO 的 1 对 1 DVN 配置，将跨链消息验证简化为单个故障点。攻击者投毒了 LayerZero Labs DVN 所信任的 RPC 基础设施，迫使其证明一条伪造的跨链消息，导致以太坊上释放了 116,500 枚 rsETH，而 Unichain 上没有任何相应的源端事件。

背景

LayerZero 是一个构建在模块化安全架构上的跨链消息协议。其核心是，跨链消息的完整性由去中心化验证网络（DVN）强制执行，DVN 是链下实体，负责独立验证源链上发送的消息在目标链上执行之前确实发生过。每个部署在 LayerZero 上的应用程序都配置其自己的 DVN 设置，包括信任哪些 DVN、需要多少 DVN 以及必须满足何种共识阈值。这种模块化使应用程序能够完全控制其安全模型，但也承担全部责任：协议本身无法为薄弱的配置提供后盾。

KelpDAO 的 rsETH 作为 LayerZero 上的 OFT（Omnichain Fungible Token）部署，其桥接路由连接 Unichain（源链）和以太坊主网（目标链）。OFT 标准允许在源链上销毁代币，并在目标链上解除锁定，跨链消息作为解除锁定的唯一授权。以太坊端适配器 (0x85d456...e98ef3) 负责在验证并传递有效跨链消息后，向接收者释放 rsETH。至关重要的是，KelpDAO 配置此路径时使用了 1 对 1 的 DVN 设置，指定 LayerZero Labs 作为唯一验证者。这意味着单个 DVN 的证明足以授权任何代币释放，无需第二次意见。

为了执行其验证职责，LayerZero Labs DVN 查询多个 RPC 节点，以确认跨链发送事件是否实际发生在其源链上。这些 RPC 节点包括自营基础设施和第三方提供商，DVN 在签署证明之前依赖于它们的集体响应。此过程的完整性取决于一个假设，即大多数被查询的节点返回真实数据。

漏洞分析

该漏洞是基础设施和配置级别的一次系统性故障，由三个复合的弱点组成。

首先，KelpDAO 的 1 对 1 DVN 配置消除了验证层的所有冗余。LayerZero 推荐的安全策略明确要求多 DVN 设置，并使用独立验证者，这样单个 DVN 无法单方面授权消息。通过仅依赖 LayerZero Labs DVN，KelpDAO 确保了该单个验证器的任何泄露都足以授权任意代币释放。

其次，DVN 的故障转移机制会将验证查询路由到任何可访问的 RPC 节点。此设计假设节点不可用是偶然的，而非故意的。然而，这创造了一种条件，即攻击者无需破坏所有数据源：通过使健康节点脱机（通过 DDoS）并准备好受污染的节点作为唯一可访问的替代方案，攻击者就可以完全控制 DVN 接收到的数据。

第三，替换 RPC 节点上的 op-geth 可执行文件需要对底层服务器进行操作系统级别的访问。具体的初始访问向量未披露，但同时破坏了两个独立节点（位于不同集群上）可能表明对这些服务器的访问控制方式存在共同的弱点。

这三个条件共同构成了一个完整的攻击链：第一个条件确保没有独立的 DVN 来交叉检查已证明的消息，第二个条件确保攻击者可以完全控制唯一 DVN 接收到的数据，第三个条件提供了使数据操纵成为可能的第一步。任何一个弱点单独都不足以完成攻击。如果没有 1 对 1 的配置，第二个查询独立基础设施的 DVN 将会拒绝伪造的消息。如果没有故障转移行为，健康节点将压倒受污染的节点。如果没有服务器被破坏，攻击者将无法注入伪造的数据。

攻击分析

以下分析基于交易 0x1ae232...4222 和 LayerZero Labs 的官方事件声明。

• 步骤 1：攻击者获取了 LayerZero Labs DVN 所信任的特定 RPC 节点列表。这份列表构成了一个高价值的情报目标，因为知道确切的节点允许攻击者计划一次精准打击，而不是一次广泛的基础设施攻击。

• 步骤 2：攻击者获得了两个 RPC 节点的操作系统级别写入权限，并用恶意版本替换了正在运行的 op-geth 二进制文件。这两个节点据称运行在独立集群上，彼此之间没有直接连接，这表明初始访问向量涉及共享的上一级依赖项（例如，被破坏的部署凭证、CI/CD 管道，或者对拥有两个节点访问权限的操作员进行社会工程攻击）。LayerZero Labs 未披露具体的初始访问方法。此步骤是所有后续数据操纵的先决条件。

• 步骤 3：恶意 op-geth 二进制文件实现了目标响应逻辑：它仅向 DVN 的 IP 地址返回伪造的交易数据，同时向所有其他请求者（包括 LayerZero 的监控基础设施、区块浏览器和扫描服务）提供真实的区块链状态。这种选择性的投毒使得攻击对所有现有可观测系统不可见；从任何外部视角来看，源链都显得正常。

• 步骤 4：DVN 的内部共识要求在受污染和未受损的 RPC 节点之间达成一致。为了解决这个冲突，攻击者在攻击窗口（太平洋时间上午 10:20 至 11:40）期间对剩余的健康节点进行了 DDoS 攻击，触发了 DVN 的故障转移逻辑，迫使其仅依赖受污染的基础设施。此步骤是必要的，因为否则健康节点会返回与伪造响应相矛盾的真实数据。

• 步骤 5：DVN 现在只接收攻击者控制的数据，一条伪造的 LayerZero 跨链消息被宣布为有效。DVN 证明了以太坊目标端上的 nonce 308，而该 nonce 在 Unichain 上没有相应的出站事件（源端仍然报告最大出站 nonce 为 307，证实了这一点）。

• 步骤 6：以太坊端的 rsETH 适配器收到有效证明的消息后，将 116,500 枚 rsETH 释放到攻击者的接收地址 (0x8b1b6c...0d3b)，该地址在数小时前已通过 Tornado Cash 预先资助。被盗代币立即分散到七个分支钱包，并通过 Aave 抵押品头寸、直接 ETH 兑换以及重新桥接到 Arbitrum 进行清算，最终收益在以太坊上的 0x5d3919...7ccc 和 Arbitrum 上的相应收款方处集中。

• 步骤 7：恶意二进制文件在完成执行后触发了自毁例程，删除了自身以及所有本地日志和配置文件。这极大地阻碍了事件后的取证恢复，并展示了攻击者的操作复杂性。

• 步骤 8：攻击者试图利用同一路径再获取 40,000 枚 rsETH（约 9500 万美元）的后续尝试被阻止，此前 KelpDAO 检测到异常并暂停了以太坊主网和 L2 上的所有相关合约 [2]。

更广泛的影响

造成的损害远超最初的 2.9 亿美元桥梁被盗事件。攻击者将约 89,567 枚 rsETH（约 2.21 亿美元）存入 Aave 的多个市场，并以 E-Mode 93% 的 LTV 借入 WETH [4]。由于 Aave 无法区分合法桥接的 rsETH 和通过伪造消息释放的代币，因此“被毒害”的抵押品被视为完全有效。由此产生的 WETH 储备冻结传播到以太坊、Arbitrum、Base、Mantle 和 Linea，影响了那些对 rsETH 毫无接触的用户。这种从单个桥梁配置错误到多链借贷市场中断的连锁反应，说明了 DeFi 可组合性如何放大单个故障点的范围和成本。

后续事件也引发了关于去中心化运营现实的重要问题。LayerZero Labs 宣布其 DVN 将不再为使用 1 对 1 配置的应用程序签名消息 [1]，这表明协议级别的去中心化本身无法弥补应用程序级别的配置弱点。

在链级别，Arbitrum 安全委员会执行了一项紧急操作，冻结了攻击者在 Arbitrum One 上持有的 30,766 枚 ETH。正如 BlockSec 分析的那样 [5]，这是通过链级别的强制状态转换实现的：安全委员会临时升级了以太坊收件箱合约，注入了一条冒充攻击者地址的未签名 L1 到 L2 消息，然后恢复了原始实现，所有这些操作都无需持有者签名 [3]。

这项行动是治理定义的紧急权力的一次合法行使，公开进行并与执法部门协调。但它也表明，L2 链在设计上保留了集中干预能力：原则上，Arbitrum One 上的任何资产都可以通过安全委员会通过相同的机制进行转移。正如本事件在各个层面所显示的，系统理论信任模型与其实际信任边界之间的差距，正是最重要风险所在。

结论

本事件表明，桥梁安全不能仅仅归结为协议的正确性。LayerZero 协议本身按照设计运行；漏洞完全存在于其上方的操作层面。核心教训是，链下验证基础设施是信任边界的一部分，其安全态势必须与它所保护的价值相匹配。

三个缓解措施中的任何一个都可以单独阻止这种情况发生：

• 多 DVN 配置：要求多个独立 DVN 达成共识，将单个 DVN 的泄露不足以授权消息，无论该 DVN 被欺骗到何种程度。
• 故障转移感知 RPC 选择：在主动验证窗口期间，节点可访问性突然下降应被视为潜在攻击信号，而不是常规可用性事件。DVN 实现应停止或发出警报，而不是继续使用缩减的节点集。
• RPC 基础设施加固：在生产 RPC 节点上替换正在运行的可执行文件的能力表明底层服务器的访问控制不足。DVN 依赖的、用于获取源链真实情况的 RPC 基础设施，应受到与 DVN 签名实例本身相同的安全边界的约束。

更广泛地说，任何依赖链下证明的桥梁或跨链协议，都应该审计的不仅仅是智能合约层，而是从源链事件到目标链执行的整个数据管道。当数亿美元依赖于 RPC 基础设施时，RPC 基础设施默认可信的假设已不再站得住脚。

参考资料

[1] LayerZero Labs, "KelpDAO Incident Statement," April 20, 2026. https://x.com/LayerZero_Core/status/2046081551574983137

[2] KelpDAO, "April 18 Incident: Additional Context," April 21, 2026. https://x.com/KelpDAO/status/2046332070277091807

[3] Arbitrum, "Security Council Emergency Action," April 21, 2026. https://x.com/arbitrum/status/2046435443680346189

[4] LlamaRisk, "rsETH Incident Report," April 20, 2026. https://governance.aave.com/t/rseth-incident-report-april-20-2026/24580

[5] BlockSec, "Arbitrum Security Council Freeze Mechanism Analysis," April 21, 2026. https://x.com/Phalcon_xyz/status/2046467830498173088

本周更多事件

Hyperbridge

2026 年 4 月 13 日，Hyperbridge，以太坊上的一个跨链消息桥，因 MMR（Merkle Mountain Range）证明验证逻辑中缺少输入验证而被盗约 24.2 万美元。MerkleMountainRange.VerifyProof() 函数未强制执行 leaf_index < leafCount，允许攻击者伪造跨链证明并执行特权操作，包括铸造 1,000,000,000 枚 DOT 代币。

背景

Hyperbridge 使用以太坊端验证器和分发器模型进行跨链消息。在以太坊上，HandlerV1 合约使用提供的证明与存储的 overlayRoot 进行验证，如果证明被接受，它会将消息分发到目标模块，例如 TokenGateway 合约。

TokenGateway 合约是一个特权的资产管理模块。除了正常的资产桥接外，它还支持治理风格的操作，如资产创建、注销和管理员管理。对于桥接的 ERC6160Ext20 代币，管理员可以通过调用 changeAdmin() 函数直接转让铸币权限，然后新管理员可以通过 mint() 函数铸造任意数量的代币。

这意味着整个资产桥的安全性取决于 HandlerV1 中证明验证路径的正确性。如果伪造的消息能够通过验证，下游模块会将攻击者控制的有效载荷视为真实的跨链指令。

漏洞分析

核心问题在于 HandlerV1 合约 (0x6c84ed...6d64) 中的 MMR 证明验证流程。入口函数 handlePostRequests() 首先基于攻击者提供的输入构建 MmrLeaf(leaf.kIndex, leaf.index, commitment)。然后调用 MerkleMountainRange.VerifyProof() 执行证明验证。

MerkleMountainRange.VerifyProof(root, request.proof.multiproof, leaves, request.proof.leafCount)

然而，VerifyProof() 只检查 root == CalculateRoot(proof, leaves, mmrSize)，而不验证每个 leaf.index 是否在范围内（即 leaf.index < leafCount）。通过选择 leafCount = 1 和 leaf_index = 1，攻击者导致 CalculateRoot() 跳过将伪造的请求承诺折叠到计算出的根中，直接返回峰值根。这破坏了消息与证明的绑定，并允许任意有效载荷通过，作为与历史 overlayRoot 相关的有效证明。

攻击分析

以下分析基于交易 0x240aeb...1109 [1]。

• 步骤 1：攻击者 EOA 0xC513...F8E7 在同一笔交易中部署了辅助合约 0x518A...8f26 和 0x31a1...ca9AB。

• 步骤 2：辅助合约 0x31a1...ca9AB 通过 HandlerV1 中的脆弱验证路径提交了伪造的请求。由于 VerifyProof() 未拒绝越界 leaf_index，伪造的请求承诺被省略了根计算，但证明仍然匹配历史 overlayRoot。

• 步骤 3：伪造的消息被接受后，HandlerV1 将其分发到 TokenGateway，执行 ChangeAssetAdmin 操作。这会将 DOT 代币的管理员更改为攻击者控制的辅助合约 0x31a1...ca9AB。

• 步骤 4：辅助合约铸造了 1,000,000,000e18 枚 DOT 代币。

• 步骤 5：辅助合约通过 Odos Router V3 将新铸造的 DOT 代币兑换成 108.2 枚 ETH。

• 步骤 6：攻击者将 108.2 枚 ETH 转入其 EOA 账户。

结论

此事件是由 Hyperbridge MMR 验证逻辑中的不当证明验证引起的。由于未强制执行 leaf_index < leafCount，攻击者可以伪造一个承诺从未实际包含在计算根中的消息，但仍能通过与历史状态根的验证。缓解措施应在证明验证之前强制执行严格的边界检查，例如 leaf_index < leafCount。

参考资料

[1] BlockSec, "Hyperbridge Attack Analysis," April 13, 2026. https://x.com/Phalcon_xyz/status/2043601549893738970

Dango

2026 年 4 月 13 日，Dango，一个构建在 Cosmos AppChain 上的永续期货 DEX，因缺少符号检查而被盗约 150 万美元。replenish_insurance_fund() 函数使用了 is_non_zero() 而不是 is_positive() 来验证输入金额，导致攻击者可以提供负值的 UsdValue 并将保险基金提取到其保证金头寸中。

背景

Dango 是一个构建在 Cosmos AppChain 上的永续期货 DEX。用户将 USDC 作为抵押品存入永续合约，并通过链上中心化限价订单簿（CLOB）来开设 BTC、ETH 和 SOL 等资产的杠杆头寸。每个用户的抵押品余额在永续合约内被追踪为一个保证金账户。

为了保护流动性提供者（LP）免受坏账损失，协议维护着一个保险基金：存放在永续合约内的 USDC 储备金，用于覆盖清算头寸的抵押品不足以完全偿还其债务时造成的任何短缺。如果没有它，这种短缺将直接由 LP 承担。任何用户都可以从其永续账户中向保险基金贡献保证金。

漏洞分析

根本原因在于合约 0x90bc84...bea4f 中的 replenish_insurance_fund() 函数，它未能拒绝负输入金额。该函数有两个检查，但都无法阻止负的 amount：

1. ensure!(amount.is_non_zero()) 检查金额不为零，但未检查是否为正。
2. ensure!(user_state.margin >= amount) 检查用户是否有足够的保证金，但任何正数保证金都满足 >= 负数。

通过这两个检查后，函数执行 user_state.margin.checked_sub_assign(amount) 和 state.insurance_fund.checked_add_assign(amount)。当 amount 为负时，减去它会增加用户的保证金，而加上它会减少保险基金，完全颠倒了预期的资金流向。

攻击分析

交易：

第一阶段：

在交易 1 中，攻击者执行了以下步骤来消耗 Dango 的保险基金：

• 步骤 1：攻击者通过存入 1e6 枚 USDC 来开设一个保证金头寸。这是调用 replenish_insurance_fund() 的先决条件。

• 步骤 2：攻击者使用负数 amount（即 -1500000）调用 replenish_insurance_fund()。由于验证不当，负数 amount 被接受，导致保险基金的资产被提取到攻击者的保证金头寸中。

• 步骤 3：攻击者提取了保证金头寸中的所有资产，获得了 1,500,000 美元的 USDC。

第二阶段：

在交易 2-8 中，攻击者调用 transfer_remote() 将被盗资产桥接到以太坊。结果，410,000 美元的 USDC 被桥接到以太坊。

结论

此攻击的本质是，在无符号上下文中使用了有符号整数类型，但没有符号检查。UsdValue 类型本身是签名的（永续 PnL 可能是负数），但保险基金捐赠路径仅对正贡献有意义。使用 is_non_zero() 而不是 is_positive() 留下了一个仅一词之差的漏洞，允许任何调用者颠倒资金流向，从而将 USDC 从保险基金中提取到他们自己的保证金中。攻击者在单笔交易中完成了整个攻击（存入 1 美元，提取 150 万美元，提取 1,500,001 美元），然后缓慢地将资金桥出。桥接速率限制是限制损失的唯一机制：如果没有它，全部约 150 万美元都将被无法追回地桥接到以太坊。

Rhea Finance

2026 年 4 月 16 日，Rhea Finance 在 NEAR 上的一个借贷和保证金交易协议 Burrowland，因其保证金交易模块的业务逻辑缺陷而被盗约 1840 万美元。在开立杠杆头寸时，协议依赖 verify_token_out() 来验证预期的兑换输出，然后才接受该头寸。然而，该函数在 token 匹配最终输出 token 时，错误地累积了中间兑换步骤的 token_out 金额，未能考虑到这些中间金额随后被用作 token_in。攻击者部署了假代币和假池，然后构建了一个循环兑换路径，该路径夸大了感知输出金额并使其通过了偿付能力检查，从而从协议中窃取了约 1840 万美元。

背景

Burrowland 是 NEAR 上的一个开源借贷和保证金交易协议。除了标准的存贷功能外，它还支持保证金交易，并引入了三个关键变量来表示用户的杠杆头寸：token_c（抵押品）、token_d（债务资产）和 token_p（头寸资产）。

对于多头头寸，用户将 token_c 作为抵押品存入，并以选定的杠杆（例如 5 倍）借入 token_d。然后，借入的 token_d 在 DEX 上兑换成 token_p，即用户想要获得敞口的资产。在正常情况下，token_p 的价值大约等于花费的 token_d 的价值。协议代表用户持有 token_p，同时将借入的 token_d 记录为债务。

对于空头头寸，用户同样存入 token_c 并借入 token_d（他们想要做空的资产）并施加杠杆。借入的 token_d 被兑换成另一种资产（token_p），有效地做空 token_d。同样，在正常市场条件下，兑换预期会保值。

在头寸的整个生命周期中，token_p 仍由协议托管，用户不能直接提取。头寸必须平仓才能实现利润或损失，届时 token_p 将被兑换回 token_d 以偿还债务。

保证金头寸的开立由 internal_margin_open_position() 处理，该函数设置头寸参数并将借款分发到 DEX。

在协议接受新头寸之前，它会按顺序评估四项保护措施：is_min_amount_out_reasonable() 将用户声明的 min_token_p_amount 与 Pyth 预言机隐含的兑换输出进行交叉检查，以限制滑点；is_open_position_liquidatable() 验证预期的头寸和抵押品价值是否通过清算线；is_open_position_forcecloseable() 验证账户在纸面上是否没有已不偿付；get_open_position_lr() 强制执行 token_d / token_c 价值不超过最大杠杆率。

所有四项检查都使用 min_token_p_amount 作为头寸资产的价值，因为兑换尚未执行，也没有实际可用的金额。因此，每道防线的正确性都取决于 min_token_p_amount 是否与 DEX 实际交付的金额绑定。这种绑定正是用户提交的兑换消息的 verify_token_out()，通过 RefV1TokenReceiverMessage::get_token_out() 实现的，其作用是强制执行。

漏洞分析

缺陷在于 verify_token_out() 内部。该函数选择最后一个兑换步骤的 token_out 作为最终输出代币，然后对产生相同代币的每个兑换步骤声明的 min_amount_out 求和，假设每个这样的产生都贡献了最终输出。这对于真正的多路径（拆分路由）兑换来说是正确的，但它并未排除那些 token_out 被立即用作下一步 token_in 的步骤。往返路径，如 A->B->A->B，会导致每个 ->B 步骤都被计入总和，尽管其输出在随后的 B->A 步骤中被消耗，并且永远不会到达 Burrowland。verify_token_out() 批准的求和 min_amount_out 不再代表 DEX 实际返回的金额。

一旦绕过了 verify_token_out()，膨胀的 min_token_p_amount 就会在 internal_margin_open_position() 中被视为事实。本应阻止不安全开仓的每个偿付能力检查都是基于伪造的数字进行的，因此头寸被接受，协议将借来的 token_d 发送到 DEX，并附加了循环兑换消息。

攻击分析

以下分析基于交易 GcXEKm...fnFT。

第一阶段：假代币和假池部署

攻击者部署了三个假代币并创建了五个假池。

1. 假代币 ID：

   1. Fake1：31623e1d98275d2b0db4f50e102f6bf40877c1345e06e4ca6727f58c89564bb2

   2. Fake2：6a28e3d3c7af1415ec22c6264013e1138bab00f85b8b6055d882d7d46afdf49b

   3. Fake3：e081e03daf58f5bb04cf95a03017e58449b76e704f1974771d7e3bd52835b6e5

2. 假池 ID：

   1. Zec-Fake1：7509

   2. Fake1-Fake2：7510

   3. USDC-Fake2：7511

   4. Fake2-Fake3：7512

   5. Fake3-USDC：7513

第二阶段：保证金头寸开立

• 步骤 1：攻击者利用 Burrowland 的保证金交易功能，以一个有合法价值的资产作为 token_c，一个真实储备资产作为 token_d，开立了一个杠杆头寸，并附带一个交易信息，其操作列表是一个完全通过攻击者在第一阶段控制的池子路由的往返 A->B->A->B。

• 步骤 2：由于 verify_token_out() 对每个 token_out 与最终代币匹配的步骤的 min_amount_out 求和，往返路径允许攻击者将声明的 min_token_p_amount 任意膨胀。

• 步骤 3：膨胀的 min_token_p_amount 通过了 internal_margin_open_position() 中的所有开仓时间健康检查，因此头寸被接受，协议将借来的 token_d 发送到 Ref-Finance。

• 步骤 4：循环兑换只返回了极少量的 token_p；on_open_trade_return() 在没有任何重新检查的情况下记录了它，导致头寸从创建之初就处于不偿付状态。

• 步骤 5：借入的 token_d 结算在攻击者控制的路径中的池子里；攻击者通过 remove_liquidity() 将其提取出来。

• 步骤 6：由于借款是杠杆化的，提取的 token_d 的价值高于存入的 token_c。差额是每个周期的净利润，不可收回的债务被强制清算为 protocol_debts。攻击者重复了该构造，直到大约 1840 万美元被消耗。

结论

此事件是由 Burrowland 保证金开仓路径中的业务逻辑缺陷引起的。RefV1TokenReceiverMessage::get_token_out() 函数在中间输出与最终代币匹配时，错误地聚合了中间输出，假设这些金额将作为最终输出保留。然而，循环兑换路径打破了这个假设，因为这些代币可以在路径中被重复使用和消耗。因此，计算出的 min_token_p_amount 会被人为地膨胀，导致所有后续的偿付能力检查都依赖于不正确的值，从而允许在伪造的健康状态下开立头寸，而无需验证实际收到的金额。

对于生产中的保证金交易合约，开发者应：

• 将用户声明的 min_amount_out 视为未经验证的输入，并仅采用最后一个环节的 min_amount_out，或明确拒绝那些重新消耗先前产生的 token_out 的兑换路径（没有通过目标代币的循环）。
• 将声明的滑点与预言机隐含的兑换输出的上限和下限进行绑定，这样攻击者就无法单方面膨胀声明值以绕过偿付能力断言。

关于 BlockSec

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

BlockSec 在顶级会议上发表了多篇区块链安全论文，报告了数起 DeFi 应用的零日攻击，阻止了多次黑客攻击挽救了超过 2000 万美元，并保障了数十亿美元的加密货币。

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

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

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

• 🔗 Phalcon Security APP：预约演示

• 🔗 Phalcon Compliance