XRPL安全性在xrpl批处理修正漏洞被阻止在主网之前得到加强

XRPL基金会在xrpl批量修正案影响主网之前，已阻止了与之相关的严重问题，突显了账本不断发展的安全姿态。

投票阶段发现关键漏洞

XRPL基金会披露，在提议的批量修正案中发现了一个关键漏洞，并在主网激活前予以消除。该漏洞在变更仍处于验证者投票阶段时浮现，使开发者能够在正式影响之前做出响应。

该问题于2026年2月19日由安全工程师Pranamya Keshkamat与Cantina AI的自主工具Apex共同发现。根据基金会的说法，用户资金从未面临风险，因为该修正案尚未在XRPL主网上启用。

该修正案正式名为XLS-56，旨在引入XRP账本上的批量交易。它将允许多个内部交易被组合成一个批次，从而提高效率和协调性。然而，这些内部交易被故意留空签名，授权委托由列出签名者的外部批量交易负责。

签名验证漏洞的工作原理

根据基金会的事后分析，漏洞根源于批量功能的签名验证逻辑。此外，问题集中在用于验证批量授权的签名者验证函数中的循环错误。

当系统遇到一个签名者条目，且该账户尚不存在于账本中时，可能会提前退出循环。如果签名密钥与新账户匹配，验证过程会被错误地标记为成功。这样，软件就会跳过对批量中所有剩余签名者条目的检查。

这种行为为未授权交易打开了通道。攻击者可以在没有私钥的情况下，从受害账户执行操作，因为对这些账户的密钥检查可能被绕过。在发现时，该修正案仍处于验证者投票阶段，并在主网上保持禁用状态。

XRPL基金会强调，提案尚未激活，并重申：“修正案处于投票阶段，尚未在主网上激活；没有资金面临风险。”这一保证对于限制市场担忧和强调严格预激活测试的益处至关重要。

批量修正案漏洞的潜在影响

报告的利用场景需要精心设计的批量交易。攻击者会构建一个包含三个内部操作的批次，利用签名验证中的漏洞。

首先，一个内部交易会创建一个由攻击者完全控制的新账户。其次，另一个内部交易会从该新账户提交简单的转账或操作。第三，从受害账户向攻击者账户发起一笔支付，试图在没有合法授权的情况下转移资金。

为了完成设置，攻击者会提供两个批量签名者条目。一个签名者条目对应新创建的由攻击者控制的账户，另一个虚假声称授权受害账户的交易。然而，由于提前退出循环的漏洞，系统可能会接受第一个签名者，而未能正确验证第二个。

因此，受害者的支付可能在没有有效签名的情况下被执行，导致账本被篡改，受害者未授权的操作发生。XRPL基金会警告称，如果此技术被大规模使用，可能会导致任意资金转移和账本的破坏性变化。

此外，组织强调，如果此类漏洞被带到主网，可能会损害整个生态系统的信任。Spearbit首席执行官Hari Mulackal和Cantina的CEO Hari Mulackal评论道：“我们的自主漏洞猎手Apex发现了这个关键漏洞。”Ripple工程团队随后复现了该行为，制作了概念验证，并在修复漏洞前完成了全面的单元测试。

紧急响应与rippled更新

披露后，XRPL的UNL验证者被迅速建议对批量提案投“否”票。这一协调确保在修复过程中，修正案不会意外突破激活阈值。

2026年2月23日，发布了紧急软件版本rippled 3.1.1。该版本明确标记了原始批量修正案和相关的fixBatchInnerSigs变更为不支持状态。因此，它们被阻止获得验证者投票，不能在任何生产网络中启用。

该紧急版本未包含最终修正的逻辑，而是作为一层保护屏障，确保批量和fixBatchInnerSigs都无法在其缺陷版本中激活。然而，这一措施为开发者争取了宝贵的时间，以设计和审查更安全的替代方案。

已实施的修正方案名为BatchV1_1，作为原始设计的继任者。该更新移除了签名验证中的提前退出，并加强了对所有授权路径的检查。基金会确认，该修订仍在审查中，尚未安排部署日期。

加强XRPL安全措施

事件发生后，XRPL基金会提出了额外的安全措施，以增强开发流程的安全性。此外，计划扩大人工智能在协议变更审查中的作用，以更早发现细微的逻辑错误。

该组织打算增加AI辅助的代码审计，借助Cantina AI的工具和Apex系统的成功经验。同时，将扩大静态分析，特别检测循环中提前成功返回等模式，这些都曾导致批量验证逻辑中的漏洞。

不过，基金会强调，XRPL批量修正案事件显示了多层防御的重要性，包括人工审查、自主分析和分阶段激活。通过结合这些方法，维护者旨在减少未来协议升级中未被发现漏洞的风险。

最终，XRPL基金会强调，关键漏洞在主网激活前已被修补，且资金未受到影响。早期发现、协调验证者响应以及快速的rippled紧急发布，共同帮助防止了未授权交易，维护了XRPL网络的完整性。