Ledger紧急修补程序修复了可能铸造18.5万亿枚代币的漏洞

18.5万亿枚XRP的溢出风险

攻击路径穿过了订单簿。攻击者本可以在XRP Ledger内置交易所中布置特殊价格的挂单,使支付引擎的记账发生溢出,从而让账本从未创建的XRP变成可花费代币。理论上约18.5万亿枚的规模,几乎是网络固定的1000亿枚流通供应量上限的185倍。这直接威胁账本的核心供应保障:伪造的XRP本可以完全花费,而非仅仅显示错误,溢出一旦发生,总量上限在实践中将形同虚设。开发团队以紧急补丁封堵了这条路径,随xrpld 3.4.1于9月25日发布。

XRPL基金会的漏洞披露报告将缺陷追溯到BookStep,即在支付经由账本内置交易所路由时为挂单定价的聚合代码。以特定模式排列的挂单可使引擎溢出,击穿XRPNotCreated不变量。这一防线写于2017年,用于阻止XRP在协议规则之外凭空产生。安全公司Veria在实际环境中演示了该路径,将伪造代币在一系列钱包地址之间转移,同时让每个账户都保持在账本的账户余额上限之内,因此失衡从未在任何单一账户上暴露。Veria估计理论敞口约940亿美元。时间线非常紧凑:漏洞于9月22日星期二确认,修复次日合入代码库,修补版本于9月25日星期五随xrpld 3.4.1发布。确认、合并与发布,每一步都落在四天之内。RippleX的审查未发现该缺陷曾被用于攻击主网的迹象。绕过常规修正案投票的决定在10月12日星期一重新引发关注,紧急补丁公告当时在X上广泛传播。

为何没有请验证者投票

按照XRPL的常规治理,验证者需要就交易处理规则的变更进行为期数周的投票,新规则生效时网络获得一个统一的切换点。目前排队等待的修正案走的正是这条路。这次的修复没有。若先公开代码再等待激活,攻击者可能在多数服务器仍运行易受攻击软件时拿到一份可用的攻击配方,因此开发团队直接发布了补丁,每台服务器升级至3.4.1后即对其生效。

这一例外本身也带风险。滚动更新期间,不同版本的服务器可能以不同方式处理同一笔漏洞利用交易,令网络对账本状态产生分歧。好在窗口很短:Veria统计到9月25日已有超过80%的验证者升级至新版本。缺陷的严重程度是这次决定的关键,按标准流程等待两周,等于给攻击者留出在网络暴露期间动手的时间。这次事件也让代码的年龄留下了记录:BookStep自2015年起就是软件的一部分,XRPNotCreated不变量自2017年起与之并存,直到多年后才有人找出击穿二者组合的方法。

XRPL基金会的披露报告同时涵盖了溢出漏洞与绕过修正案流程发布的选择,并明确指出,这是一次针对可能创造出远超原始供应量的可花费XRP的威胁的紧急响应,而非账本治理的新模板。验证者本月还在权衡其他协议议题,包括是否在10月23日前解除共识机制相关的PaymentBurn委托禁令。

悬而未决的治理问题

披露报告是这里的关键文件,它直截了当地写明边界:没有铸造任何代币,18.5万亿这个数字衡量的是漏洞可能触及的规模,而非实际发生的损失。我们的判断是,总量上限之所以守住了,是因为它由代码强制执行,而不依赖任何人的托管。缺陷从未触及任何一枚私钥,攻击的是决定XRP何时存在的记账逻辑。这也框定了报告留下的问题:面对破坏供应的漏洞,紧急补丁可以辩护,但如果为较轻的威胁反复绕过流程,赋予账本规则权威性的验证者程序将被侵蚀。升级在9月25日前已基本完成,且无任何被利用的记录,消息来源显示持币者没有剩余的应对步骤。在我们的讨论持续期间,XRP技术分析追踪市场一侧的表现,我们的区块链安全审计指南则讲解如何解读这类披露报告。