摘要:Ripple工程总监维贾伊·卡纳呼吁所有XRP Ledger节点运营商立即升级至xrpld 3.2.1版本,以应对7月底爆发的验证器清单洪水攻击。该热修复通过四项机制限制异常数据处理,防止资源耗尽风险。

币圈界报道:
XRP Ledger节点运营商须紧急升级至3.2.1版本应对安全威胁
8月2日,Ripple工程总监维贾伊·卡纳正式敦促所有XRP Ledger节点运营商尽快部署xrpld 3.2.1版本,此前于7月31日发现一次针对验证器清单系统的分布式攻击行为。
漏洞事件触发快速响应与热修复发布
此次安全事件源于对等网络中大量未授权验证器身份信息的异常传播,导致部分节点面临内存占用激增、带宽压力和处理负载上升的风险。为应对这一挑战,开发者迅速推出xrpld 3.2.1版本,实施多项防护策略,涵盖清单大小限制、消息批次控制、出站共享抑制以及未知密钥缓存增长管控。系统在事件期间持续稳定运行,分类账正常关闭,无资金损失或共识失败记录,且尚未公布相关CVE编号或财务影响评估。
四重防护机制有效遏制异常数据扩散
新版本引入四大核心防御措施:一是提前拦截过大的验证器清单,避免解码前的高计算开销;二是限制单个消息中包含的未受信清单数量,适用于接收与发送双场景;三是将未知身份缓存上限设定为100,超限则拒绝新增条目;四是调整未受信任数据的传播逻辑,仅限制非可信节点间的闲谈行为,保障已认证验证器的密钥轮换流程不受干扰。
重启操作是清除残留数据的关键步骤
卡纳强调,运营商应在完成软件更新后等待一至两分钟,确认服务状态正常,并执行第二次重启。此举旨在彻底清除可能已在内存中滞留的异常清单数据,确保后续运行环境纯净。此外,系统信任链也需同步更新——因Ripple已于2月18日更换GPG签名密钥,未导入新密钥的旧安装将无法接收自动升级包。
事后分析报告待发布以厘清事件全貌
截至8月2日,运营团队尚未发布详细的技术复盘报告。当前仍不清楚攻击发起者的具体身份、传输的数据规模、受影响节点的实际资源消耗情况,以及首次检测时间点。未来报告还将评估是否有节点因延迟升级而再次暴露于风险之中。尽管分类账整体运作正常,但若补丁普及率不足,个别服务器仍可能重复遭受冲击。此次热修复恰逢XRPL主版本3.2.0上线不久,后者已完成名称变更与配置重构,进一步强化了对基础设施合规性的要求。
声明:本站所有文章内容,均为采集网络资源,不代表本站观点及立场,不构成任何投资建议!如若内容侵犯了原著者的合法权益,可联系本站删除。
