概述
一个在支付引擎中留存了大约十年的关键XRP账本漏洞，理论上可能允许攻击者创建超出账本预期供应规则的可花费XRP。XRPL于2026年10月9日披露了该问题，此前该问题于9月22日通过XRPL漏洞赏金计划被私下报告。该漏洞影响xrpld 3.4.0及更早版本，并在9月25日发布的xrpld 3.4.1中修复。
该XRP账本漏洞涉及当一笔支付消耗数百个特制订单簿报价时的整数溢出。单个报价所有者可以获得其全部XRP金额，而买方仅被收取一个很小的回绕总额。更严重的是，账本现有的“不创建XRP”不变量使用了类似的算术路径，并可能以相同方式溢出，导致该安全检查无法检测到差异。
XRPL表示，未发现该漏洞在任何公共网络上被利用的证据，正常支付也不会意外触发它。该攻击需要故意设计的价格在经济上不现实的报价。即便如此，该事件引发了一个更深层的安全问题：区块链的固定货币政策，其强度取决于执行每一次余额转换的软件。
关键要点
- 该漏洞似乎自2015年当前XRPL支付引擎编写以来就一直存在。
- 一笔故意构造的交易理论上可能创建可花费的XRP。
- XRPL未发现其在公共网络上被利用的证据。
- 现有的供应不变量可能失效，因为它重现了相同的溢出行为。
xrpld 3.4.1添加了受检查的算术和更强的独立供应检查。
什么是XRP账本漏洞？
该漏洞存在于XRP账本支付引擎对订单簿流动性的处理中。当一笔支付经过多个报价时，引擎必须计算付款人总共欠多少XRP。每个单独金额可能有效，但聚合计算使用了一个64位整数，且没有足够的溢出保护。
在普通条件下，这实际上无法触及。XRP的正常供应量和真实市场价格远未接近使计数器溢出所需的数值边界。只有当攻击者故意构造数百个报价，其中每个账户以极少量另一种代币索取极大量XRP时，问题才会出现。
恶意流程大致可能如下：
- 创建数百个受控账户。
- 从这些账户放置故意不现实的报价。
- 构造一笔旨在同时消耗这些报价的支付。
- 将聚合XRP计算推至整数限制之外。
- 导致总额回绕为一个小得多的数字。
然后，引擎可以分别贷记报价所有者，而仅向买方收取溢出后的总额。由于攻击者也可以控制报价所有者账户，差额实际上变成了新的XRP。
XRPL工程师在本地复现了该攻击，并确认生成的XRP随后可以被转移。因此，该问题从重大提升为严重级别。
XRP账本漏洞真的能创建XRP吗？
是的，理论上可以。这不仅仅是会计显示错误。XRPL的技术披露称，该漏洞利用可能在恶意交易被验证后创建行为类似普通XRP的XRP。这些余额可以被移动、交易或发送到交易所。
这并不意味着XRP在历史上被超额发行。XRPL报告称，它发现没有证据表明该漏洞利用在任何公共网络上发生过。这两种说法的区别至关重要：该漏洞可能违反预期的供应约束，但目前没有确认的与之相关的历史供应事件。
该攻击也不可能在正常DEX交易中意外发生。订单簿报价的定价必须如此不现实，以至于正常市场流动性会在触及它们之前执行。支付还必须被故意构造，以同时消耗足够多的这些报价来触发溢出。
因此，最好将其理解为低概率执行路径，但具有极高的理论影响，而不是普通XRP用户可能无意中触发的错误。
为什么XRPL的供应安全检查失败了？
该事件在技术上最重要的部分，并不仅仅是存在整数溢出。成熟的金融软件通常包含多个防御层，专门用于捕获这类意外结果。
XRPL有一个：一个交易不变量，旨在确保交易不能创建XRP。原则上，即使支付引擎出现会计错误，该不变量也应该注意到XRP总余额增加并拒绝该交易。
但它没有。
原因在于所谓独立安全系统的经典失效。该不变量使用类似类型的未检查算术来计算净 XRP 变化。当支付引擎发生溢出时，不变量计算可能朝同一方向溢出，使最终交易看起来只改变了普通交易手续费那么多的 XRP 供应量。
当一项安全检查能够复现它所检查系统的同一失效模式时，它就不是真正独立的。
第二道防护检查单个账户余额是否超过 XRP 总供应量。这同样未能阻止攻击，因为新创建的 XRP 可以分散到数百个账户中，使每个单独余额都低于上限。
因此，修复措施既解决了直接漏洞，也处理了防御架构问题。xrpld 3.4.1 在跨报价和支付路径聚合金额时增加了显式溢出检查。XRPL 还将“未创建 XRP”不变量改为使用更宽的计数器，使其在相同条件下不会发生回绕。
为什么一个 2015 年的漏洞能隐藏这么久？
答案部分在于现实经济价值与理论计算机极限之间的差异。单笔 XRP 支付的操作量级远低于使 64 位总和溢出所需的范围。普通交易者可以使用 XRPL 多年，而不会制造出任何类似恶意数值条件的情况。
这使得该缺陷难以通过日常使用暴露出来。易受攻击的逻辑可以在数十亿次正常操作中表现正确，却仍在人为边界处灾难性地失效。
该漏洞还表明，为什么长期存在的区块链代码不应仅仅因为运行多年就被自动视为安全。生产历史是有用证据，但它主要测试的是常见状态。攻击者则刻意寻找普通用户从未制造过的状态。
XRPL 将其漏洞赏金计划归功于发现了该问题，并概述了一种更广泛的纵深防御方法，包括独立审计、公开攻击马拉松、模糊测试、AI 辅助红队测试和形式化验证。它还在正式关闭发现之前，针对发布候选版本增加对安全修复的重新验证。
这种方法很重要，因为此次事件的教训并不是成熟代码不可信任。而是成熟代码仍然需要针对开发者多年前就不再质疑的假设进行对抗性测试。
这个漏洞对 XRP 的固定供应量意味着什么？
XRP 最初定义了 1000 亿枚代币的初始供应量，没有类似工作量证明挖矿那样持续创造额外 XRP 的协议机制。交易手续费被销毁，而不是支付给验证者，因此预期的供应路径是非通胀性的。
XRP Ledger 漏洞揭示了作为规则的货币政策与作为软件执行的货币政策之间的重要区别。
区块链规范可能声明不能创建新的 XRP，但节点最终通过代码来执行该属性。如果余额转换逻辑可以被操纵以违反该规则，那么即使成文政策没有改变，经济政策本身也可能失效。
此次事件并未表明 XRP 的实际流通供应量被秘密增加。XRPL 表示未发现公共网络上的利用行为。但它确实表明，在补丁之前，存在一条理论上的执行路径，能够绕过该账本最基本的货币约束之一。
这使得该漏洞比暂时的 RPC 中断或节点连接问题更具影响。网络可以容忍某些基础设施中断而不损害资产完整性。一个能够生成可花费单位的漏洞则触及账本本身的会计基础。
为什么修复比没有发生利用更重要
一旦调查人员表示漏洞从未被利用，人们很容易就此忽视它。但这会错过更有用的安全教训。
XRPL 的响应时间线相对紧凑：该问题于 9 月 22 日被报告并复现，修复在 9 月 22 日至 23 日期间开发并审查，合并到 3.4.1 发布分支，并于 9 月 25 日发布。XRPL 报告称，超过 80% 的默认唯一节点列表验证者当天就在运行受保护的版本。
支付引擎修复也随软件升级直接生效，而不是等待正常的修正案激活流程。这之所以可行，是因为拒绝算术溢出被视为修复未定义或不安全行为，而不是引入新的预期交易规则。
对于区块链安全而言，披露时机是防御的一部分。在验证者受到保护之前公布漏洞利用方法，会将一个理论上的漏洞变成攻击者的操作指南。因此，XRPL 在修补版本已经传播之后才披露技术细节。
风险与局限
该事件很严重，但有几条界限应当保持清晰。
- 没有已确认的通胀事件：XRPL 表示未发现公共网络上存在利用行为的证据。
- 没有意外触发：正常支付和现实的订单簿不会达到所需数值。
- 补丁采用很重要：服务器运营者应运行
xrpld 3.4.1或更新版本。 - 一次修复并不能证明完全安全：其他旧的算术假设仍值得进行对抗性测试。
- 历史上未被滥用不能替代形式化验证：某些类别的漏洞过于罕见，无法通过正常网络活动浮现。
另一个局限是回溯确定性。调查人员可以分析账本历史和已知的漏洞利用模式，但证明某个漏洞从未被使用，与从数学上证明它不可能被使用，本质上并不相同。因此，官方结论被恰当地表述为未发现证据，而不是对每一个历史状态作出绝对断言。
MEXC 观点：固定供应量是一种软件安全属性
区块链的货币政策并非仅由文档中写下的供应量数字来保障。它是由验证每一次余额变动、交易路径和账本状态的软件来保障的。
XRPL 事件说明了这一区别为何重要。该协议的预期规则禁止创建新的 XRP，但算术中的一个缺陷理论上可能违反该规则。更重要的是，旨在捕获供应量创建行为的防御性不变量最初也共享了同样的失效模式。
因此，对于成熟的区块链网络，安全需要超越测试正常交易是否正确运行。独立不变量、模糊测试、对抗性边界测试和形式化方法变得越来越重要，恰恰因为最具破坏性的漏洞可能存在于普通用户从未触及的代码路径中。
在此次披露之后，值得关注的指标不是 XRP 价格反应。而是 XRPL 扩展后的验证流程能否在攻击者之前持续发现并隔离类似类别的潜在协议风险。
这个存在十年的漏洞很关键，但并非已证实的 XRP 通胀事件
XRP Ledger 漏洞配得上“关键”这一描述，因为它理论上可能破坏 XRPL 最根本的保证之一。一笔精心构造的支付可以强制触发 64 位算术溢出，为数百个报价所有者记入 XRP，而只向买方收取总金额的一小部分。在 XRPL 自身对攻击的复现中，新创建的余额是可花费的。
但故事的另一半同样重要。XRPL 发现没有公共网络利用的证据，该交易需要刻意异常的订单簿条件，并且该漏洞在技术细节公开披露之前已在 xrpld 3.4.1 中修补。
因此，该事件不应被改写为 XRP 供应量在历史上曾被通胀的证据。其意义更具结构性。它表明，即使是固定供应量的区块链，最终也依赖于软件在可能多年不可见的边缘情况下正确执行货币约束。
因此，从这一 XRP Ledger 漏洞中得出的最强结论，关乎协议工程，而非代币供应量头条。货币不变量需要独立实现，旧代码仍需要对抗性审查，而十年来成功的网络运行并不能消除隐藏边界条件故障的可能性。该漏洞并未证明 XRP 曾被超额发行；它证明了为什么供应完整性必须被持续验证。
来源
XRPL 官方漏洞披露：
https://xrpl.org/es-es/blog/2026/vulnerabilitydisclosurereport-bug-20261009
XRPL 3.4.1 发布信息：
https://xrpl.org/blog
想最快获取 MEXC 最新资讯？立即加入我们的官方电报群！
MEXC 平台：下载 App | 零手续费交易 | 立即购买 USDT 加入 MEXC 社群：X (Twitter) | Telegram | Discord
获取资讯：新手学院 | 服务条款 | MEXC Blog | MEXC News
账户验证：了解 KYC | 如何进行 KYC
