XRP Ledger发布热修复应对验证器清单洪水威胁

8月2日，Ripple工程总监维贾伊·卡纳正式敦促所有XRP Ledger节点运营商尽快部署xrpld 3.2.1版本，以防范此前在7月31日被发现的验证器清单洪水攻击事件。

漏洞触发后迅速发布应急补丁

此次安全事件源于对等网络中异常大量未识别验证器身份信息的传播，促使开发者紧急推出xrpld 3.2.1版本。尽管分类账持续稳定关闭，但系统检测到节点间通信与资源消耗出现异常波动。为遏制风险，新版本引入四重防护机制，分别针对清单大小、消息批次、出站共享及未知密钥缓存增长进行严格控制。

核心防护机制阻断攻击路径

在攻击发生前，节点可接受、缓存并转发由未知验证器发布的合法结构清单。攻击者借此生成海量虚假身份，迫使对等节点过度占用内存、带宽和计算资源。官方将此问题归类为清单传播缺陷。xrpld 3.2.1版本于7月31日发布，并于次日凌晨作为最新签名版本上线，共包含13个文件中的6项更新，其中4项直接聚焦于未受信任清单的处理限制。

四重防御策略有效抑制资源滥用

第一项措施在解码前拒绝过大的验证器清单，降低攻击者通过超大对象引发高负载的可能性；第二项限制单条消息中携带的未受信任清单数量，适用于接收与发送双重场景，避免因大批量数据导致连接中断；第三项设定未知身份缓存上限为100个，超过即拒绝新清单，同时保留已知可信节点的正常运作能力；第四项调整未受信任信息的传播逻辑，仅限制非授权节点间的闲谈行为，不影响已认证验证器的密钥轮换流程。

重启操作是清除残留数据的关键步骤

卡纳强调，运营商应在完成软件更新后等待1至2分钟，确认服务运行状态，随后执行第二次重启。此举旨在清除可能已在内存或存储中持久化的异常清单数据，确保系统从源头上摆脱旧有污染。此外，系统需验证是否已信任Ripple于2月18日更换的GPG包签名密钥，否则自动升级功能可能失效。

事件影响范围尚待全面评估

截至8月2日，运营团队尚未发布详细的事后分析报告，相关细节如攻击发起者身份、传输总量、受影响节点的具体资源消耗情况仍不明确。后续报告预计将涵盖首次检测时间、是否存在节点宕机现象以及各网络区域的补丁采纳进度。虽然分类账始终正常闭合，但若部分节点延迟升级，仍可能面临重复攻击风险。