AI 发现的 XRP Ledger 漏洞暴露出铸造 18.45 万亿 XRP 的路径

Veria AI 发现了一个 XRP Ledger 漏洞，研究人员称，尽管该加密货币的总供应量固定为 1000 亿 XRP，该漏洞仍可能铸造 18.45 万亿 XRP。

这一漏洞利用将账本支付引擎中的错误算术运算，与一个重复相同错误的安全检查结合在一起。经特殊构造的一笔支付可向数百个卖方账户入账，而买方几乎无需支付任何成本。

RippleX 复现了该漏洞，将其定级为严重漏洞，并于 2026 年 9 月 25 日发布 xrpld 3.4.1。 官方披露称，调查人员没有发现任何人曾在公共网络上利用该漏洞的证据。

这一区别至关重要。这并非一起涉及 18 万亿 XRP 的盗窃，也不意味着理论上的数量具有可实现的市场价值。它是一条可信的路径，足以违反 XRP 最核心的供应量规则。

这起事件也检验了围绕 AI 辅助安全的一项更大承诺。一个 AI 代理似乎发现了一项存在近十年、且未被审计和传统测试发现的缺陷。然而，人类研究人员仍需验证结果、协调保密修复，并说服验证者升级。

XRP Ledger 漏洞在公开披露前已获修复

眼前的故事，是一次针对一个近十年来始终可被触及漏洞的成功紧急响应。

Veria Labs 表示，它将其安全代理用于 rippled，即 XRP Ledger 所使用的开源服务器软件。该公司称，其系统识别出存在漏洞的代码、开发出可用的漏洞利用程序，并在本地网络上进行了测试。

该公司的技术复盘将 AI 的首次发现追溯至 9 月 21 日。Veria 称，该系统次日便生成了一个可用的概念验证。

研究人员 Cayden Liao 审核了这一结果，并于 9 月 22 日通过 XRPL 漏洞赏金计划进行报告。RippleX 工程师当天就在独立服务器和其测试框架内复现后确认了问题。

确认不止于展示账目差异。RippleX 证实，新创建的 XRP 可以在后续支付中转移，使产出的 XRP 在实际操作中可被花费。

开发者于 9 月 23 日合并修复方案，并在两天后发布 rippled 3.4.1。公开披露延至 10 月 9 日，以便运营者有时间安装修复后的软件。

Veria 表示，超过 80% 的验证者在 9 月 25 日运行了该版本。XRPL 官方账户同样报告称，默认 Unique Node List 上超过 80% 的验证者在当天完成升级。

Unique Node List，或 UNL，用于识别服务器在评估共识时信任的验证者。这些验证者的快速采用，降低了旧节点继续接受漏洞交易所带来的风险。

这一响应偏离了修改交易行为的常规路径。XRPL 通常通过修正案引入对共识敏感的变更，验证者会在激活前对此进行考量。

开发者转而将溢出修复直接纳入服务器版本中。他们暂时未公开相关源代码变更，以降低攻击者在足够多验证者完成升级前逆向分析漏洞的可能性。

这一选择在短期内将信任集中于维护者和验证者运营者身上。同时，它也避免公开的修正案流程变成一份可立即利用的通胀漏洞操作手册。

官方报告称，XRPL Foundation、RippleX 和参与的验证者认为，保密升级比让一个公开漏洞在数周内持续可用更安全。在网络达到必要的安全阈值后，修复内容才被公开。

Veria 于 10 月 8 日获得了最高级别的严重漏洞赏金，金额为 25 万美元。这一金额反映的是严重性评级，不应被误解为已测量的损失。

未发现未经授权的 XRP，没有用户报告资金丢失，也没有任何公共账本交易被关联到该漏洞利用。此次紧急响应针对的是代码会接受什么，而非已经观察到的损失。

这样的结果很容易让人低估事件的重要性。不过，未遭利用并不会降低一个可能推翻资产固定供应量假设的缺陷的重要性。

XRP Ledger 漏洞如何创造可花费的 XRP

该漏洞之所以能够生效，是因为两项货币安全保障几乎以相同方式进行了存在漏洞的计算。

第一个缺陷出现在支付引擎处理 XRP Ledger 内置去中心化交易所报价单的方式中。报价单允许账户通过账本的订单簿交换 XRP 或发行资产。

攻击者首先会创建多个受控账户，并发行一种毫无价值的代币。随后，这些账户会挂出数百笔人为报价，要求以极高数量的 XRP 交换该代币。

Veria 的概念验证使用了 256 笔报价。每笔报价要求略高于 2^56 drops，其中一个 drop 等于百万分之一 XRP。

攻击者随后会提交一笔支付，设计为消耗整组报价。支付引擎必须先将每笔报价对应的 XRP 数额相加，才能向买方扣款。

该总额超出了计算中所使用无符号 64 位整数的容量。整数溢出是指数值超过允许的最大值后，回绕成一个小得多的数。

在这里，累计数额超过了 2^64 drops。各个报价所有者可以获得全额，而溢出使买方的合计扣款看似仅为 256 drops。

这比错误的兑换报价更严重。入账余额代表的是没有任何源账户提供的 XRP。

在扣除源账户借记额和交易费之前，结果约为 18,446,744,073,709 XRP。Veria 将可用产出概括为分布在 256 个账户中的约 18.45 万亿 XRP。

这种分配至关重要。XRPL 对单个账户持有的 XRP 设有上限，但每位接收者都能维持在该上限以下。

因此，该攻击通过将新 XRP 分散到大量账户中，绕过了一项安全保障。研究人员称，这些入账的 XRP 随后可以通过普通支付转移，或流入交易所。

XRPL 还设有一项旨在防止这类结果的不变量。所谓不变量，是指账本接受变更前必须保持为真的交易后安全条件。

XRPNotCreated 不变量会计算整笔交易中 XRP 余额的净变化。若结果显示交易创造的 XRP 多于其通过费用销毁的数量，它本应拒绝该交易。

然而，这一计算采用了同样易受溢出影响的算术运算。净变化发生回绕，最终看起来像一次普通的费用销毁，从而使交易得以通过。

实际上，支付引擎错误计算了买方应付的金额。随后，看似独立的供应量检查重复了这一数学错误，并批准了虚假的结果。

这种共同失效是关键的设计教训。当备用控制措施依赖与被监控组件相同的数据类型、算术行为或假设时，其保护作用十分有限。

这并非普通交易者会意外触发的攻击。它需要数百笔经过刻意定价的报价，以及一笔专门设计用以同时消耗它们的支付。

它还需要一些 XRP 用于账户和报价储备，以及交易费用。漏洞报告估计所需资金为数百 XRP，其中大部分储备金之后可以收回。

攻击者无需控制验证者。准备并签名后，这笔漏洞利用交易将以一笔看似普通的支付形式进入网络。

该攻击还可以重复实施。额外的受控账户组能够重新创建这一设置，从而再生成一批 18.45 万亿 XRP。

修复方案在报价求和代码中引入了溢出检查。超过允许范围的总额如今会直接失败，而不再回绕为一笔很小的扣款。

开发者还扩大了供应量不变量所用累加器的位宽。其他余额求和路径也获得了相关加固，以降低再次出现共同算术失效的可能性。

固定供应量让潜在损害具有系统性

真正的风险并不是 18.45 万亿 XRP 不可能实现的面值，而是每一枚已在流通的合法 XRP 的可信度。

XRP 的初始总供应量为 1000 亿枚。它不通过挖矿或质押产生，普通交易费用则会随着时间推移销毁少量 XRP。

这一设计赋予用户一个简单的货币预期：交易可以重新分配 XRP，但绝不应增加总供应量。

XRP Ledger 漏洞在账务层面违反了这一规则。若遭利用，它可将新创建的 XRP 放入普通账户，而不会明显标记这些余额有何不同。

报道所称的 18.45 万亿 XRP 产出约为初始供应量的 184 倍。然而，用这一数量乘以市场价格会得出一种误导性的经济损失衡量方式。

攻击者无法以攻击前的价格卖出数万亿 XRP。可用流动性会迅速消失，交易所可能暂停交易，且在大多数代币找到买家之前，价格就会作出反应。

更有意义的参考指标是 Veria 评估该漏洞时 XRP 约 940 亿美元的市值。这代表着其底层稀缺性假设面临压力的价值规模。

即便这一数字也不是有保证的损失估计。市值并不等于存放在网络中的现金，不同持有者面临的结果也会不同。

系统性风险来自信心。未经授权的发行可能稀释现有持有者权益、压垮交易所流动性、扰乱应用，并引发对账本会计保障的质疑。

机构同样会面临运营不确定性。交易所可能需要识别受影响的充值，支付服务商可能暂停结算，托管机构则可能在调查期间限制提款。

即使攻击者仅攫取标题数字中的一小部分，这些反应仍可能伤害合法用户。供应量失效的影响会扩散至直接涉事账户之外。

这有助于解释为何采用保密发布。维护者保护的不仅是协议，也包括交易所、验证者和基础设施提供商可用于响应的时间窗口。

根据 Veria 的分析，该缺陷很可能自支付引擎于 2015 年编写时便已存在。供应量不变量中的第二项弱点则可追溯至 2017 年。

这一时间线对“长期运行本身即可证明安全”的观点构成压力。软件可以处理数十亿笔交易，同时保留一条正常活动永远不会触发的漏洞利用路径。

Ripple 在 3 月表示，自 2012 年以来，XRPL 已处理超过 1 亿个账本和 30 亿笔交易。这些数字证明其使用范围广泛，但并未覆盖所有可能的算术状态。

这里关键在于罕见输入。由于合法 XRP 供应量远低于溢出所需阈值，正常支付无法接近触发溢出所需的数值。

攻击者必须在大量挂单中伪造极端的订单簿数值。基于合理经济行为的常规测试，可能从未探索过这种组合。

审计同样未能消除风险。Veria 表示，自 2024 年起，该代码库已接受十余次审计或审计竞赛，同时还设有成熟的漏洞赏金计划。

这并不证明这些审计敷衍了事。审计受到时间、范围和激励机制的限制，而罕见的交互问题可能隐藏在彼此独立的组件之间。

其中的教训更具体，也更有用：成熟的金融代码需要能够挑战机器极限的测试，而不只是模拟普通用户行为的场景。

AI Security 发现了漏洞，但由人类控制了风险

这项发现支持 AI 辅助安全的价值，而应对过程也说明，自动化扫描只是协议防御的其中一层。

Veria 将漏洞发现和漏洞利用构造都归功于其 AI 安全代理。该公司称，该系统分析了 rippled，关联起两处算术弱点，并构建了可在本地运行的概念验证。

这一说法意义重大，因为该漏洞需要跨组件推理。仅仅发现支付溢出，并不能保证攻击成功，因为供应量不变量可能会拒绝该交易。

据称，该代理识别出该不变量也重复了同一种溢出。随后，它设计了一项输入，在同一笔交易中触发两处失败。

Veria 的说法获得了有意义的外部支持。RippleX 独立复现了该漏洞利用，确认被铸造 XRP 可以花费，并将报告的严重程度从重大提升为严重。

XRPL 的官方披露并未对该代理的自主性作出完整评估。它确认了报告和技术结果，但未独立衡量人类指导在发现过程中发挥了多大作用。

在评估 AI 安全产品时，这一缺口很重要。一次成功发现可能以不同的比例涉及自动化代码分析、人类编写的提示词、迭代审查和手动漏洞利用验证。

即便如此，这起事件仍提供了比基准测试分数更有力的证据。它促成了一项已确认的严重漏洞、一次生产环境发布，以及最高额度的漏洞赏金支付。

Ripple 此前已于 2026 年 3 月宣布一项更广泛的 AI security program。该计划将 AI 辅助测试与专门的红队、模糊测试、形式化验证以及更严格的修正案审查相结合。

模糊测试会向软件输入意料之外或格式异常的数据，以暴露崩溃和无效状态。形式化验证则运用数学技术来检验软件是否满足既定属性。

这些方法应对的是不同的失效模式。AI 可以检查代码并提出攻击路径，模糊测试器可以探索输入空间，而形式化方法可以检验关键不变量。

人类工程师仍需判断一项发现是否可被实际触发、其影响是否真实，以及如何在不破坏共识的情况下修复问题。他们还要在去中心化运营者群体中管理漏洞披露。

XRP Ledger 的应对清晰展现了这种分工。代理找到了路径，Liao 对其进行了审查，RippleX 则在受控环境中复现了漏洞利用。

随后，开发者修改了多条算术路径。验证者运营者安装了该版本，维护者则在披露细节前监测采用情况。

没有任何单一参与方控制整个结果。该系统依赖于一家私营安全公司、开源开发者、一个基金会、RippleX 以及独立运营者之间的协作。

这种协调是一项优势，因为多方审查了这一发现。但它同样是一项值得审视的治理依赖。

在源代码层面的说明公开之前，紧急补丁已经发布。验证者必须在无法获得常规变更通常具备的透明度时，决定是否信任该版本。

另一种选择也存在风险。在广泛采用前公布确切的溢出机制，会为攻击者提供针对每个未修补验证者的可行攻击路径。

这才是核心权衡，而非 AI 审计与人工审计之间的一场简单较量。更快的发现提升了快速、可信且经过审慎治理的响应程序的价值。

帮助防御者检查旧代码的同类工具，也能帮助攻击者寻找等效错误。RippleX 工程师 Mayukha Vadari 在披露中警告称，AI 改变了漏洞发现与利用之间的时间窗口。

因此，成熟的计划需要的不只是更好的扫描器。它还需要经过演练的保密披露机制、明确的严重性标准、验证者沟通渠道，以及可衡量的升级准备度。

XRP Ledger 漏洞并不能证明什么

已确认的漏洞利用极其严重，但若干新闻标题式的解读超出了现有证据。

首先，没有证据表明 18.45 万亿 XRP 已进入公共账本。研究人员是在验证漏洞时，于受控环境中创建了该输出。

其次，没有任何来源证实攻击者在 Veria 报告之前已知晓这一攻击路径。易受攻击代码存在的时长描述的是暴露时间，而非已确认的对手知情情况。

第三，所谓 940 亿美元的风险不应被视为损失预测。它描述的是稀缺性保证可能受到损害的市场规模。

第四，这起事件并不能证明 AI 系统独立完成了研究的每个阶段。Veria 对该代理的角色提供了最详细的说明，而人类负责审查和披露。

这些限制条件并不意味着这一发现只是可被轻视的理论问题。RippleX 复现了该交易，并确认后续付款可以花费新生成的 XRP。

该漏洞也已进入生产代码。这并非像同一 3.4.1 版本中修复的另一项 Batch 交易问题那样，是在启用前捕获的拟议功能。

将这些事件混为一谈可能造成困惑。Batch 漏洞涉及封装器验证，以及服务器版本之间可能出现的分歧。

该 Batch 修正案尚未在主网上启用。验证者通过修正案投票处理其修复，修正后的版本于 10 月 9 日启用。

XRP 溢出则走了不同路径。它影响既有支付引擎行为，并在节点安装 3.4.1 版本后立即得到修复。

因此，release record 包含两项安全修复，它们的暴露情况和治理历史各不相同。只有支付溢出产生了所称的铸币路径。

另一项不确定性涉及历史检测。XRPL 表示未发现公共网络上存在漏洞利用的证据，但读者应区分“没有证据”与绝对证明不存在。

使用该漏洞的攻击者会造成异常的余额变动和订单簿活动。尤其考虑到需要数百笔人为挂单，这些痕迹应有助于追溯性分析。

不过，公开披露并未提供完整的取证方法，也未提供对账本历史进行独立审计搜索的结果。其结论仍是维护者报告的发现。

网络的快速升级也值得持续审视。默认 UNL 验证者中超过 80% 的采用率降低了即时风险，但其他节点和基础设施提供商遵循不同的时间表。

一纸披露声明无法让旧版软件变得安全。运行 rippled 3.4.0 或更早版本的运营者仍有责任升级。

最后，这一事件并不表明 AI 已使区块链审计变得完备。它表明，一个 AI 辅助流程在成熟代码库中发现了一个重要漏洞。

下一项考验是可重复性。安全团队需要证据证明，类似系统能够发现多样化、此前未知的漏洞，同时不会以大量低质量报告淹没维护者。

他们还需要评估对抗性使用。只有当修复与部署速度能够快于恶意复现时，更快的防御性发现才有价值。

三项信号将显示安全模型是否得到改善

下一阶段应通过代码、验证者行为以及可由独立方复现的安全结果来评判。

第一项信号是持续采用 rippled 3.4.1 或更高版本。关键的溢出修复在软件安装时生效，因此过时节点仍是最明显且可避免的风险。

公共验证者遥测数据应显示，易受攻击的版本正从具有实质共识作用的角色中消失。采用缓慢将削弱 XRPL 能够在紧急情况下协调行动的说法。

第二项信号是对货币不变量进行超出本次特定补丁范围的技术审查。失效的供应量检查与其本应监控的组件共享了算术行为。

开发者应使用更宽的累加器和显式的溢出处理，测试其他总额、转换和余额路径。独立审查比又一次泛泛的保证更能增强信心。

第三项信号是证明 AI 辅助测试能在负责任的披露机制下产出可重复的发现。已确认的漏洞、较低的误报率以及清晰的人类监督，将支持 Veria 更广泛的主张。

一连串耸动却未经验证的报告会削弱这一主张。那些在变得可执行前需要大量未披露的人类重构的发现，同样如此。

这起事件已经改变了安全基准。长期运行、既往审计和递减供应设计，都未能阻止一次机器极限错误威胁 XRP 的核心货币规则。

与此同时，公开漏洞利用出现前，应对机制已经发挥作用。研究人员报告了问题，工程师复现了它，验证者在数日内安装了紧急修复。

开发者和基础设施运营者现在应当思考：他们自己的安全检查是否会以不同于其所监管系统的方式失效。重复的假设并不是真正的纵深防御。

对于关注 XRP Ledger 漏洞的读者，最有用的行动是观察版本采用情况、独立代码审查以及未来的漏洞赏金披露。这些信号将揭示，这究竟是一次孤立修复，还是更强安全模型的开端。