此段代码，是指 IVAL 库在计算 Hash 过程需要考虑 pin.Left 和 pin.Right 均大于 0 的情况，事故发生后官方增加此段代码，是为了可以避免发生同类情况。

在后续 IApplication(handlerContract).handleSynPackage 处理中，合约给黑客增发 100 万个 BNB。

系统预编译合约 0x65 对应 iavlMerkleProofValidate 功能：

系统合约 0x65 实现代码如下，主要逻辑为使用 DecodeKeyValueMerkleProof 解码输入参数，并调用 Validate 进行校验：

其中 kvmp.Validate() 实现代码如下：

IAVL 的 Proof 校验过程中，Hash 计算存在漏洞，导致黑客可以在 Proof 添加数据，但计算 Hash 时并没有用到添加的数据。详细分析如下：

在 len(pin.Left) 不为 0 的分支中，计算 Hash 并没有使用 pin.Right 数据。黑客利用该处漏洞构造数据，添加 proof.LeftPath[1].Right 数据，但是该数据并不参与 Hash 计算。

根据上述分析，正常数据组织结构如下，proof.LeftPath[1].Right 为空值，计算得到正确的 Hash。

黑客构造攻击数据结构如下，添加 proof.LeftPath[1].Right 数据，且该数据不参与 Hash 计算。

黑客攻击构造的数据中，包括了 IAVL:V 和 multistore 相关数据，multistore 数据也是基于 IAVL 进行操作，原理是一样的，不再进行详细分析。

这次 IAVL Proof 暴露的问题在于，数据局部的变化无法反应到整体，使得校验发生错误。在 Cosmos 生态中，IBC 使用 ICS23 来做数据的校验处理，ICS23 与 IAVL Proof 校验不同点在于，ICS23 会对所有的“叶子节点”的值进行数据校验，最后计算得出的根 Hash 再与链上数据进行校验，OKC 采用的是 ICS23 的 Prove，因此不存在 BNBChain 这次遇到的安全漏洞。

链上卫士团队利用黑客攻击交易数据，基于 BNBChain 单元测试代码，增加了基于黑客攻击交易的测试用例，可以完整复现黑客的攻击交易。

单元测试代码利用 iavlMerkleProofValidate.Run 接口验证输入数据，即相当于调用预编译合约。

利用黑客攻击交易数据，构造新的 payload 数据为 value := []byte(“okc test hack”)，并对 proof 相应数据进行了修改，即修改 proof.LeftPath[1].Right 和 proof.Leaves[1]对应的数据，新构造的数据可以通过 okcIavlMerkleProofValidate 校验，即修改了黑客数据也能通过校验。

另外，如下单元测试代码对原始黑客数据和修改后的数据两种 case 都进行了校验，且校验都能成功，从而说明如下测试代码利用本文所述漏洞成功进行了复现。

跨链桥，作为区块链的基础设施之一。其自身的中心化特性，为去中心化的 Web3 世界引入了中心化风险，其安全性很大程度上取决于跨链桥项目方自身。

本次黑客攻击通过构造了一个包含多 Leaves 的 Proof 数据，绕过 BNBChain 上的校验，从而在 BNB 链造成了 BNB 增发。相较以往线下漏洞、私钥泄露等攻击方式，这次攻击难度更高，且涉及金额更大，据统计涉及金额在 8.5 亿左右，创下历史新高。

目前 OKLink 多链浏览器已对 BNB Chain 黑客地址进行风险标签标记（标记为“Hack”），关于此次被盗后续，链上卫士团队还将进一步追踪案件细节并及时同步。