XRP Ledger 中的一名溢出漏洞曾可能使单笔交易创造出超过现有全部供应量的 XRP。Ripple 的开发部门 RippleX 与 XRPL Foundation 已披露并修复了这一很可能自 2015 年起就存在的漏洞，修复时间为 2026 年 9 月下旬。没有证据表明该漏洞曾被利用。

本可能被打破的供应上限

XRP Ledger 是 XRP 背后的去中心化区块链。它通过内置的订单簿处理支付和交易，支付引擎则是将付款与订单簿中挂单进行匹配的组件。总供应量在上线时为 1000 亿枚 XRP。该网络没有挖矿，也没有通胀，只有被销毁的交易手续费会略微减少供应量。这一固定上限依赖于账本层面的不变量——即任何交易都不得创造 XRP 的规则——而这正是此次溢出漏洞所破坏的保障。

xrpld 服务器软件 3.4.1 版本于 9 月 25 日发布，披露报告则在 14 天后发布。在此之前，Default Unique Node List（UNL）上超过 80% 的验证节点已完成升级。该漏洞影响 xrpld 3.4.0 及所有更早版本。报告该漏洞的 Veria Labs 计算，一笔利用交易本可创造约 18 万亿枚 XRP。

漏洞如何凭空铸造 XRP

支付引擎会对支付在订单簿中消耗的所有挂单金额求和，使用的是没有溢出检查的 64 位整数加法。如果总和增长到足够大，数值就会回绕为一个较小的数字。每个挂单所有者本会收到全额付款，而账本只从买方扣除回绕后的金额。差额将以新 XRP 的形式凭空产生。

本应有两道保障机制阻止这种情况。然而，规定任何交易不得创造 XRP 的不变量使用了同样的会溢出的算术运算。此外，单账户余额检查只有在超过总供应量时才会触发，而新创造的 XRP 会分散到许多账户中。

实施这种攻击时，攻击者需要设立数百个账户，每个账户以极小的代币份额挂单购买巨额 XRP。单笔支付随后会消耗所有挂单，而涉及的每个账户都可以属于攻击者。成本仅为几百枚可回收储备金 XRP 加上手续费，因此攻击者不需要庞大的初始资金。

尽管如此，没有人能够偶然触发该溢出。正常的支付永远达不到所需的金额，因为不会有真实交易者报出这样的价格。报告还指出，没有任何公共网络上存在被利用的证据。Veria Labs 的 Cayden Liao 表示，该攻击串联了两个单独来看严重程度均为低的漏洞，他猜测这正是此前无人发现该缺陷的原因。

通过漏洞赏金计划报告

Cayden Liao 与 Veria AI 于 9 月 22 日通过网络的漏洞赏金计划报告了该漏洞，最初将其评级为“Major”。RippleX 复现了攻击并将其评级提升为“critical”，随后私下开发修复方案。一天后，修复进入 3.4.1 版本的发布分支，并随候选版本 3.4.1-rc1 发布。从那时起，支付引擎在对挂单金额求和时会检查溢出；如果总和溢，该部分支付即告失败。

只有 Veria Labs 提供了关于发现过程本身的细节。该公司表示，是一个 AI 智能体发现了该漏洞并构建了可运行的攻击程序。相比之下，披露报告中仅将 Liao 和 Veria AI 列为报告者。约 18 万亿枚 XRP 的数字来自 Liao 的计算，相当于总供应量的 184 倍。Veria 还表示其获得了 25 万美元的最高赏金，但报告并未提及具体金额。此类计划是各大区块链网络中奖励负责任披露的标准机制。

根据报告，该漏洞很可能自 2015 年支付引擎开发时就存在于代码中，在约十年的时间里未被发现。这一案例契合 AI 辅助漏洞挖掘这一更广泛的趋势——它能够更快地暴露缺陷——RippleX 的开发者也持相同观点。

无需修正案的修复

XRP Ledger 上的规则变更通常需要通过所谓的修正案，这要求在两周内获得超过 80% 可信验证节点的支持。然而，此次修复随着每台服务器各自升级而立即生效。报告称，这是自修正案机制推出以来，首次有意以这种方式变更交易处理逻辑。发布当天，已有超过 80% 的 Default UNL 验证节点运行 3.4.1 或更高版本。

RippleX 以时间窗口为由解释了这一举措：常规的开源发布会在修复生效前数周就向攻击者暴露漏洞所在。因此，XRPL Foundation 成员、RippleX 和 XRPL 验证节点事先达成一致，认为风险证明了快速处理方式的合理性。在他们看来，只有最严重的漏洞才适合采取这一步骤，所有其他变更仍需通过修正案流程。

"AI has changed things. You can't sneak a critical bug patch into a routine public release process, it'll get spotted and reverse-engineered immediately." — Mayukha Vadari, RippleX

然而，团队直到二进制文件发布约两周后才在 GitHub 上公布 3.4.1 源代码。Cyber Capital 创始人 Justin Bons 在 X 上批评称，XRP 曾在闭源代码上运行了两周。延迟披露的静默补丁在软件安全领域是常见做法，但在一个有治理雄心的去中心化网络中，这仍然存在争议。

批量交易功能中的第二个漏洞

3.4.1 版本还修复了批量交易功能（XLS-56）中的第二个漏洞，该漏洞影响 xrpld 3.3.0 和 3.4.0。一个批量交易最多包含八笔内部交易，根据规范，每笔交易必须位于名为 RawTransaction 的字段中。服务器此前未对此进行检查。因此，可能产生永久格式错误的账本条目，进而可能干扰索引器、浏览器和 SDK。

一个共识层面的变体更为严重。在软件版本混合的情况下，一笔精心构造的交易可能以一笔交易手续费为代价使验证停摆，不过攻击者在链上不会获得任何收益。主网未受影响，因为 BatchV1_1 在主网上并未激活。

该发现最早浮现于 Sherlock Attackathon，最初评级为“low”。9 月 18 日，XRPL Foundation 的 Denis Angell 确认此前的修复并不完整。四天后，Mayukha Vadari 识别出共识风险。随后 Ripple 和验证节点运营商 Vet 撤回了他们对 BatchV1_1 的投票，该修正案原定于 9 月 29 日激活。此次发布启动了 fixBatchV1_2 的两周激活流程，自 10 月 9 日起，两项修正案均已在主网激活。

收紧审查流程

因此，RippleX 正在改变其审查流程。从现在起，每个被标记为已修复的安全发现都必须针对候选版本进行新的测试，只有当测试能够复现原始漏洞且候选版本通过测试后，团队才会将其关闭。报告列出的其他额外保障措施还包括公开的攻击竞赛和 AI 辅助的红队测试。

较旧的版本会被视为“amendment-blocked”，不再保持同步。因此，运营商需要将服务器升级至 xrd 3.4.1 或更高版本。网络如何处理下一个关键发现——通过这条预留的快速通道还是常规修正案——将决定这种方式是否仍是报告中所描述的例外。

来源：XRPL 漏洞披露报告，经 Crypto Valley Journal