一个埋了11年的漏洞，差点让XRP凭空多出“无限货币”

原创

messfree
messfree

MessFreeSecurity

2026年10月11日 13:38
北京

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

前两天，加密圈又被一条消息刷了一波：XRP Ledger 修复了一个存在约 11 年的严重漏洞。

这个漏洞如果被利用，攻击者可以凭空造出大量能够继续转账的 XRP，直接打破“创世时生成 1000 亿枚，此后不能增发”的账本规则。XRPL 官方披露

官方已经紧急修复，并表示目前没有发现它在任何公共网络被利用的证据。这件事本身，比“又修了一个漏洞”有意思得多。

封面是原创示意图，账本行与溢出箭头不是真实链上交易。

先简单说一下 XRP 是什么

很多人第一次听 XRP，容易把它和 Ripple 公司混在一起。简单区分一下：

●XRP：XRP Ledger 上的原生资产。

●XRP Ledger（XRPL）：2012 年上线的公链，XRP 转账和跨币种支付都在这条账本上处理。

●Ripple：一家做支付技术的公司，跨境支付产品面向银行、企业和支付服务商，可以使用 XRP 等数字资产。Ripple 产品说明

XRP 的几个特点，和这次漏洞直接相关：

●　创世时生成 1000 亿枚，正常交易不能再增发，也没有挖矿产币。

●　账本结算通常约 3—5 秒；交易手续费很低，而且会被销毁。

●　XRPL 内置订单簿。跨币种支付可以在途中成交挂单，让付款人拿出一种资产，收款人收到另一种资产。XRP 官方介绍 · 跨币种支付路径

可以先把 XRP 理解成更偏向支付结算的资产。下面出问题的，正是支付途中与订单簿打交道的那段代码。

这个 11 年漏洞到底是怎么回事？

漏洞出在 XRPL 的支付引擎里。普通的 XRP 直转用不着碰订单簿；一笔跨币种支付如果要兑换资产，支付引擎就可能在途中吃掉多张挂单。

当一笔支付同时吃掉大量订单时，系统会把这些订单要求支付的 XRP 金额用 64 位整数累加。这个整数有上限。在当时受影响的版本里，累计值越过上限，没有报错，而是“回绕”成一个很小的数。

把数字缩小做个示意：一个只能显示三位的计数器，算 998＋7 本应得到 1005；如果只保留后三位，屏幕上就成了 005。真实漏洞用的是 64 位金额，这里只是解释“回绕”，不是实际交易参数。

攻击者可以这样操作：

01　创建几百个账户；

02　每个账户挂一张极端定价的卖单：用极少量其他代币，换取天文数字的 XRP；

03　再发起一笔支付，一次性把这些挂单全部吃掉。

这里有个容易误会的地方：挂单里那些天文数字是卖家要求收到的 XRP，不是攻击者一开始就得拿出来的本金。官方估计，准备账户和挂单需要先占用几百枚 XRP 的准备金，另付普通交易费。XRPL 官方影响评估

结果就是：

●　每个卖家都按自己的报价，收到了完整的大额 XRP；

●　买家却只被扣掉“回绕后”的那个小数额；

●　两边的差额，变成了凭空多出来、还可以继续花的 XRP。

图 1｜XRPL 官方披露：卖家全额入账，买家只按回绕后的合计扣款。查看原文

更关键的是，账本里原本用来防止“凭空创造 XRP”的总量检查，也用了类似的 64 位累加。支付引擎的账回绕了，这道复核的账也一起回绕，便没发现异常。

还有一道检查限制单个账户的 XRP 余额不能超过原定总量。攻击者把新增 XRP 分到几百个账户，每个账户都没有越线。这就是为什么“每个账户都合规”，不等于“全账本总量没变”。

图 2｜官方根因说明：总量复核也发生回绕；单账户上限看不到分散在多账户的增量。查看原文

现用支付引擎的这段计算写于 2015 年。约两年后加入的“不允许创造 XRP”检查，又沿用了同一类未检查溢出的加法。两道关卡看着都在，结果在同一个边界上一起失效。

官方披露了多少技术细节？

2026 年 10 月 9 日，XRPL 发布漏洞披露报告。报告把最重要的事说清楚了：哪一步累加会溢出、为什么需要几百张极端挂单、卖家与买家的账为何对不上，以及两道安全检查为什么没拦住。

RippleX 工程团队还在独立服务器和单元测试中复现了铸币，并验证新产生的 XRP 能用于后续支付。这已经不只是账面数字显示异常。XRPL 官方复现记录

但要分清三个层次：本地复现成功、公共网络被利用、已经造成实际损失，不是一回事。XRPL 目前只确认第一件事，并称没有发现任何公共网络被利用的证据。

发现方 Veria Labs 后来披露，他们一次本地测试把约 18.45 万亿枚 XRP 分到了 256 个账户，约为原定发行量的 184 倍。这是发现方的测试结果，不能拿来当作主网实际增发量，更不能直接乘上币价算“损失”。标题里的“无限货币”是形容漏洞能突破固定总量，不是说一次交易能铸出数学意义上的无限数量。Veria Labs 技术复盘

官方报告本身没有附上可直接提交的攻击交易；但发现方在 10 月 10 日公开了用于独立本地账本的复现材料，修复源码也已公开。因此，如今不能笼统说“没有 PoC 公开”，更不能把本地 PoC 误写成主网攻击记录。

为什么现在才被挖出来？

这条路径很刁钻：先铺几百张价格离谱的挂单，再让一笔支付吃掉它们，累计金额要刚好跨过整数边界；就算支付引擎算错了，还得碰上安全检查也按同样的方式算错。普通支付几乎走不到这里。

XRPL 官方致谢中列出了 Cayden Liao 和 Veria AI，确认他们通过漏洞赏金项目提交了报告和 PoC。发现方的说法更具体：AI 代理先找到支付计算和总量检查中的两处问题，把它们接成一条利用路径并完成本地复现；Cayden 随后人工复核。XRPL 官方致谢 · Veria Labs 复盘

图 3｜XRPL 确认报告和 PoC 的提交方；AI 如何工作、奖金多少，来自发现方自己的复盘。查看原文

发现方还称获得了 25 万美元赏金，并认为这是 AI 独立发现漏洞获得的最高单笔赏金之一。奖金金额和纪录说法来自 Veria 自述；XRPL 的公开报告确认了提交人和 PoC，没有公布奖金支付记录。

这件事让人看到 AI 辅助研究有多大潜力，也提醒我们：找到可疑代码只是开始。把两处错误连起来，在隔离环境里跑通，再交给工程团队复现，漏洞才从“可能有问题”变成有证据的安全事件。

这件事真正值得注意的地方

1. 老代码的风险，藏在正常交易碰不到的地方。 支付引擎的错误可以追溯到 2015 年。它运行多年，普通支付也不会偶然触发，但几百张极端挂单把整数推到了从未走过的边界。代码运行了多久，与极端路径有没有被检查过，是两回事。

2. 安全检查多一道，不一定就能兜底。 “不创造 XRP”的总量检查与支付计算用了同一类会溢出的累加；单账户上限又管不到分散在几百个账户的总量。两道检查都在，漏洞仍然穿了过去。写账本规则，复核算法也得独立经得起边界值。

3. 固定总量最终要靠代码守住。 XRP 的规则是创世发行 1000 亿枚，之后不再增发。漏洞在本地测试中打破了这条规则，官方则没有发现公共网络利用证据。把这两个结论同时讲清楚，比一句“总量不安全”或“没出事”都有用。

4. 官方反应速度还可以，但应急修复也有代价。 9 月 22 日报告并复现，9 月 25 日发布 3.4.1；支付引擎补丁随节点升级生效，没有等待常规 amendment 投票走完。官方解释，若先公开补丁、再等投票生效，漏洞会暴露数周。反过来，新旧节点短暂共存时，若有人提交特制交易，节点可能对交易结果产生分歧。官方称发布当天，默认可信验证者列表中已有超过 80% 的验证者完成升级。XRPL 官方时间线与修复说明

图 4｜9 月 22 日报告并复现，9 月 25 日发布修复，10 月 9 日公开细节。查看原文

写在最后

这起漏洞最让人后怕的地方，是防增发检查也算错了。支付引擎先把几百张订单的总价算小，检查又用相同的 64 位加法核总账，结果跟着回绕。2015 年留下的错误，2017 年新增的检查没能挡住。

发现方在独立环境里确实造出了可以继续使用的 XRP。XRPL 于 9 月 25 日发布修复；截至 10 月 9 日公开报告，官方没有发现它在任何公共网络被利用的证据。