XRPL一项尚未上线主网的修正案，险些把XRP钱包暴露在严重风险之下。安全研究人员发现，若漏洞被利用，攻击者理论上可能无需私钥就能绕过签名校验，转移用户资金或修改账本状态。所幸该漏洞出现于仍在投票阶段的 Batch 修正案（XLS-56）中，未获得足够验证者支持，因此没有进入主网，也没有用户资产受损。
这次问题由独立安全研究员 Pranamya Keshkamat 与一款名为 Apex 的自主 AI 安全工具共同发现。消息确认后，XRPL 开发者很快发布 Rippled 3.1.1，明确将 Batch 修正案标记为不受支持，直接阻断了脆弱代码被误激活的可能。
XLS-56的签名校验为何会失效
Batch 修正案原本是为了提升处理效率，允许多笔内部交易打包在一笔外层签名之下执行。按照设计，这些内部交易本身不单独签名，而是依赖外层批次的签名者列表完成授权。问题就出在这套签名校验逻辑里。
开发者解释，系统在验证授权账户时会执行一段循环检查。如果循环中遇到一个账本里尚不存在的账户，而其签名密钥又恰好与该新账户匹配，系统会过早判定校验成功。短。真正的风险在后面：软件会在这一匹配发生后提前退出循环，后续应执行的检查被直接跳过。
这种“提前退出”制造了授权绕过条件。按披露内容，攻击者可以构造特定���批处理序列，借此在缺乏合法批准的情况下发起转账，甚至改变账本状态。虽然这一攻击场景并未在现实中发生，但开发团队承认其严重性，并已在更新代码中移除相关早退逻辑，同时加强授权保护。
修正案未激活，治理流程挡住了风险扩散
这起事件没有演变成主网事故，关键原因是 XLS-56 当时仍处于验证者投票阶段，尚未拿到激活所需的共识支持。也就是说，漏洞被发现时，相关代码还没有在生产网络生效。这个时间差很重要。
XRPL 的修正案机制要求新功能在正式启用前经过验证者共识、社区审视和技术评估。此次事件中，独立研究人员的披露与自动化安全工具的检测形成叠加，给开发者留下了补救窗口。当前，修订后的修正案仍在接受同行审查，是否重新进入投票流程，报道未给出新的时间表。
从结果看，XRPL 避开了一次可能影响全网的钱包安全事件。没有资金暴露，没有交易被篡改；留下来的，是一次关于协议升级审查强度的现实提醒。