8月2日，Ripple工程总监Vijay Khanna敦促XRP Ledger节点运营商尽快安装xrpld 3.2.1版本。此前，开发者于7月31日观察到一场针对验证者清单（validator manifest）的泛滥攻击。尽管事件期间XRP Ledger网络账本正常关闭，但该漏洞仍可能对节点资源与点对点通信造成压力。
事件概述：清单洪水攻击
验证者清单是经过加密签名的记录，用于将验证者的稳定主身份与其日常验证所用的临时密钥绑定。当节点轮换临时密钥时，会发布由主密钥签名的新清单，以便其他节点验证变更。而在修复之前，节点可能接受、缓存并重新广播与未识别验证者密钥关联的结构有效清单。攻击者可利用此行为生成大量未知身份，迫使对等节点消耗内存、存储、带宽和处理能力。
四重防护机制
xrpld 3.2.1版本于7月31日发布，8月1日凌晨作为最新签名版本上线。该版本包含6个提交，涉及13个文件，其中4个提交直接限制不可信清单的处理，具体防护措施如下：
- 大小限制：在节点完整解码之前拒绝过大的验证者清单，降低单个超大对象触发的处理负载。
- 批量限制：限制单条网络消息中携带的不可信清单数量，接收和发送阶段均适用。超大批次将被丢弃，但不会自动断开未修补节点的连接，以保障升级期间新旧节点的兼容性。
- 缓存上限：将未知验证者身份在节点清单缓存中的数量上限设为100，达到上限后拒绝与新增未列密钥相关的清单，同时继续处理受信任或已识别的验证者。
- 传播控制：调整不可信清单信息的保留与传播方式，针对未列出的对等节点八卦消息进行限制，不影响已配置或已批准验证者的正常密钥轮换。
运营商需执行两次重启
Khanna建议验证者及基础设施运营商“尽快”升级至3.2.1版本。具体操作流程为：正常更新软件后，等待1至2分钟，确认xrpld正在运行，然后再次重启服务。第二次重启至关重要，因为部分节点在安装修复前可能已保留未知清单。更新可改变后续处理逻辑，而重启修正后的服务器有助于确保旧的内存或持久化数据不再影响运行。
此外，运营商可能需要确认系统信任Ripple当前的软件包签名密钥。发布说明显示，Ripple已于2月18日轮换了用于签署xrpld包的GPG密钥，尚未信任新密钥的现有安装可能无法成功自动升级。
影响范围与后续
此次更新针对基础设施提供商，普通XRP持有者无需转移资产、更换钱包密钥或创建新账户。交易所、托管机构、钱包后端、数据提供商及自营XRPL服务器的企业应确认其节点版本并检查重启状态。
XRP Ledger Operations表示“技术事后分析报告将很快发布”。截至8月2日，报告尚未公开。发送方身份、传输的清单数量以及对受影响节点的具体资源消耗仍未披露。报告还将明确开发者首次检测到该活动的时间、是否有节点中断以及节点采用3.2.1版本的速度。
此次热修复紧随XRPL 3.2.0大版本之后。3.2.0于6月15日发布，将参考服务器从rippled重命名为xrpld，并引入了需要运营商更新软件和服务配置的基础设施变更。清单洪水事件为仍运行旧版本的运营商提供了新的升级理由。相关进展包括David Schwartz将其XRPL基础设施迁移至3.2.0，以及此前节点运营商面临的与修正案激活相关的3.1.3版本截止日期。
下一次经过验证的更新将是承诺的事后分析报告和最新的软件采用数据。在那之前，已确认的应对措施仅限于3.2.1版本、四项清单控制机制以及要求运营商完成升级和重启流程。