简介
核心要点:
-
过去一周,BlockSec 在多个区块链生态中监测到 5 起具有代表性的攻击事件,总估计损失约 $104.6M。
-
三起私钥泄露事件(EchoProtocol、Polymarket、StablR)占总损失的约 $90.2M,两起业务逻辑漏洞利用(Verus、RetoSwap)造成约 $14.4M 损失。
-
Verus 跨链桥事件表明,仅凭密码学证明验证不足以保障跨链安全,对象类型的语义校验同等重要。RetoSwap 事件则表明链下协议层面的身份验证缺陷可以造成与链上漏洞同等规模的损失。
过去一周(2026/05/18 – 2026/05/24),BlockSec 监测到多起区块链安全事件。下表列出 5 起具有代表性的攻击事件,总估计损失约 $104.6M。
其中两起事件被选出进行详细分析:
-
Verus:攻击者利用 Verus-Ethereum Bridge 中的类型校验缺陷,提交了一个精心构造的 supplemental export output,桥合约将其错误分类为有效的 primary export。跨链消息语义本身即为攻击面。
-
RetoSwap:P2P 交易流程中的协议层身份验证缺陷使攻击者能通过伪造 ACK 消息劫持仲裁者角色,在链下破坏了多签钱包的创建过程。
本周看点:Verus
在本事件中,攻击者蓄意利用了一种专用的跨链 export 类型,说明其对 Verus 链内部设计有深入理解。跨链消息格式——包括 supplemental 数据字段和编码边界——本身就是攻击面,需要与密码学证明验证同等严格的审查。
2026 年 5 月 18 日,连接 Verus L1 链和 Ethereum 的跨链桥 Verus-Ethereum Bridge 遭到攻击,损失约 $11.7M 的 ETH、tBTC 和 USDC(BlockSec Phalcon Alert)(Verus Official Post-Mortem)。根本原因是 Ethereum 侧导入路径中的类型校验缺陷:桥合约接受了一个精心构造的 supplemental export output 并将其错误分类为有效的 primary export,使攻击者能提供匹配的转账数据并提取资金。截至 5 月 23 日,约 75% 的被盗资金已归还。
背景
Verus-Ethereum Bridge 的运作方式是:提交方提供证明数据,表明 Verus 链上存在一笔经公证确认的合格 export,桥合约验证通过后在 Ethereum 上释放资产。Ethereum 本身无法直接观察 Verus 交易,完全依赖提交的证明和锚定可信 Verus 状态的公证。
该事件涉及三种桥对象:primary export,即 Ethereum 导入并用于执行支付的对象;supplemental export output,即附加在 primary export 上的额外数据,不应被当作独立的活跃 export 用于支付目的;以及 notarization,用于向 Ethereum 证明某个 Verus 侧对象确实存在于已最终确认的桥状态中。
漏洞分析
存在漏洞的 Ethereum 侧桥合约部署在 0xa045…6fc87f 和 0x08f0…d0107d。
根本原因是 Ethereum 导入路径中的类型校验缺陷。桥合约验证了一个 Verus 侧对象的真实性,但在用其释放资金前,未校验该对象是否为有效的 primary export。相反,它接受了一个精心构造的 supplemental output 并将其作为正常的活跃 export 解析。
该流程中没有任何检查会拒绝设置了 FLAG_SUPPLEMENTAL 标志的对象。修复方案显式检查该标志,并在被证明的对象为 supplemental 时回退:

图 1:修复在 checkCCEValues 中显式检查 FLAG_SUPPLEMENTAL,若设置则回退
攻击分析
以下分析基于 Ethereum 交易 0x6990f0…87eb321 和 Verus 交易 f899e698…b9f5a733。
Step 1:5 月 17 日,攻击者通过 Tornado Cash 向 Ethereum 地址 0x5aBb…9D5777 注入 1 ETH。5 月 18 日,攻击者从 Verus 水龙头为地址 RW9vEW…B3g6zd 获取了 0.02 VRSC。
Step 2:攻击者在 Verus 上提交了四笔目标为 Ethereum 的 export 交易,其中包含精心构造的 supplemental export output。这些 supplemental output 的编码方式确保可被正常解析,并嵌入了 hashReserveTransfers 承诺值,该值与攻击者后续计划执行的欺诈性支付匹配。
Step 3:待跨链公证在 Ethereum 上推进到足够远,攻击者在 Ethereum 上提交了一笔伪造的导入交易。被证明的 Verus 侧对象是上述 Verus 交易中的 supplemental output。
Step 4:Ethereum 桥接受了证明,但未识别出该对象属于应被拒绝的 supplemental 数据,而是将其作为有效的活跃 export 解析。由于攻击者同时提供的 serializedTransfers 其哈希值与已承诺的 hashReserveTransfers 匹配,桥继续执行了导入流程。
Step 5:由于 supplemental output 被错误解释为有效 export,欺诈性转账通过了 Ethereum 侧检查。攻击者提取了约 $11.7M 的 ETH、tBTC 和 USDC。
Step 6:恶意导入成功后不久,Verus 节点因欺诈性 export 线程与真实 export 线程共存而触发了无效状态断言,桥的进一步运行被阻止,后续利用也因此受限。
结论
该事件由 Verus-Ethereum Bridge 中的类型校验缺陷导致:Ethereum 合约接受了真实的密码学证明,但被证明的对象是 supplemental export output,而非用于支付的有效 primary export。
由于跨链消息格式本身即为攻击面,supplemental 数据、可选字段、紧凑编码和解析器偏移量应与签名或 Merkle 证明检查同等严格对待。当对象类型与预期操作不匹配时,桥应直接拒绝而非尝试解析。
本周其它事件
RetoSwap
2026 年 5 月 20 日,基于 Monero 的去中心化 P2P 交易所 RetoSwap(Haveno 协议分叉)遭到攻击,损失约 $2.7M(7,000 XMR)。根本原因是协议层身份验证缺陷:客户端接受了伪造的乱序 ACK 消息,在未校验发送方是否与仲裁者已知公钥匹配的情况下,将仲裁者存储的 Tor 地址覆写为攻击者控制的地址。攻击者因此劫持了多签钱包的创建过程,在资金存入后立即盗取。
背景
RetoSwap 是基于 Monero 的去中心化 P2P 交易所,从 Haveno 协议分叉而来。其交易协议依赖 2-of-3 仲裁者多签模型保障交易安全,并通过 Tor 进行链下交易协调。
正常交易分为三个阶段:首先,买方、卖方和仲裁者完成链下消息交换以建立多签钱包;其次,仅在多签钱包完全创建后才将资金锁入;第三,买卖双方共同签署支付交易进行结算,或由仲裁者介入解决争议。所有通信通过 Tor 进行,每个节点仅以其 .onion 地址作为标识。
漏洞分析
5 月 20 日,Haveno 项目提交了一个标题为 “core: refuse to update node address before multisig created” 的 pull request。此时 RetoSwap 已处于被攻击状态。
补丁揭示了 TradeProtocol.java:onAckMessageAux(…) 中的漏洞。客户端使用消息中提供的 senderNodeAddress 识别对等方,但未预先通过密码学方式校验发送方是否与预期仲裁者的公钥匹配。攻击者可以发送携带攻击者控制地址的伪造 ACK 消息,客户端会将存储的仲裁者地址覆写为该地址。

图 2:handleMailboxMessage 从攻击者提供的消息中提取 senderNodeAddress

图 3:onAckMessageAux 在未验证发送方的情况下更新对等节点地址
由于这发生在第一阶段(多签钱包创建之前),攻击者的地址替换了真实仲裁者的地址。攻击者因此同时持有交易者的密钥和仲裁者的密钥,在资金存入后即可盗取全部余额。
修复方案从两方面解决:验证发送方是否与对等方的已知公钥匹配,拒绝来自未验证对等方的消息;并将地址更新限制在 trade.isDepositRequested() 之后,防止在多签钱包创建前发生覆写。

图 4:修复包含发送方公钥校验,并将地址更新约束在 deposit 请求之后
攻击分析
目前尚未识别到该事件的链上攻击交易。RetoSwap 完全通过 Tor 进行链下消息处理,关键操作发生在公共账本之外。以下攻击过程还原基于公开的补丁和官方通报。
Step 1:攻击者作为买方或卖方加入一笔现有交易。
Step 2:攻击者发送了一条伪造的乱序 ACK 消息,伪装为来自仲裁者,携带攻击者控制的 .onion 地址作为 senderNodeAddress。
Step 3:受害者的客户端接受了该消息,在未校验发送方是否与仲裁者已知公钥匹配的情况下覆写了仲裁者存储的地址。
Step 4:此后所有发往仲裁者的通信(包括多签钱包创建)均被路由至攻击者,攻击者获取了第三个多签密钥。
Step 5:在买卖双方将资金存入被破坏的多签钱包后,攻击者盗取了钱包全部余额。总利润约为 7,000 XMR(约 $2.7M)。
结论
该事件并非密码学失败,而是协议层身份验证缺陷:消息虽被验证为格式正确,但在应用地址更新前,发送方未与已知公钥进行密码学绑定。因此,客户端将伪造 ACK 消息中的 senderNodeAddress 当作仲裁者的新联系点,而此时多签钱包尚未创建,攻击者得以劫持仲裁者角色。
核心教训:(1)任何更新对等方身份的消息,在应用更新前必须通过对等方已知公钥进行密码学校验;(2)对手方地址等安全关键状态在进入敏感阶段(如多签钱包创建)后应不可变。
1

被折叠的 条评论
为什么被折叠?



