The XRP Ledger (XRPL) has disclosed a critical vulnerability in its payment engine that could have allowed an attacker to create new XRP beyond the network’s fixed supply of 100 billion tokens and spend it like any other XRP. The flaw sat undetected in the code for about a decade and was fixed before any known exploitation, according to the network’s developers.
The details were published in an official Vulnerability Disclosure Report on October 9, 2026. The report covers two bugs fixed in xrpld 3.4.1, which XRPL developers described at launch as an emergency release to fix security-sensitive issues. xrpld, formerly known as rippled, is the reference server software that validators and node operators run to process transactions on the XRP Ledger. When Crypto Times covered the xrpld 3.4.1 update for node operators on September 25, the payment engine flaw had not yet been made public.
How the XRP Overflow Bug Worked
The XRP Ledger has a built-in decentralized exchange (DEX) where users place offers to trade XRP and other tokens. When a single payment consumes many offers from this order book, the payment engine adds up the XRP owed across all of them. According to the disclosure report, that sum used plain 64-bit integer addition with no overflow check.
XRP balances are stored as integers with a fixed maximum value. When a sum exceeded that maximum, it did not fail with an error. Instead, it wrapped around to a very small number. The engine then credited every offer owner with their full requested amount while charging the buyer only the wrapped-around total. The difference was new XRP that should never have existed.
Two existing safety checks failed to catch the problem. The ledger’s “no XRP created” invariant, a built-in rule that confirms no transaction creates XRP, used the same kind of 64-bit counter, so it wrapped around in the same way and saw only a normal transaction fee. A separate per-account check fails only when a single account holds more than the total XRP supply, and the attack avoided this by spreading the minted XRP across hundreds of accounts.
The report states that the bug had likely been present since the current payment engine was written in 2015, and that the invariant check added two years later was built on the same unchecked arithmetic.
What an Attack Would Have Required
An attacker would have created a few hundred accounts, placed an offer from each one selling a tiny amount of a token for a very large amount of XRP, and then sent one payment that bought through all of those offers at once. The buyer would have been charged only a few hundred drops, the smallest unit of XRP, plus the transaction fee.
According to the impact assessment, the real cost was a few hundred XRP in account and offer reserves, which are returned when those objects are removed, plus ordinary fees. The minted XRP could then have been moved, traded, or sent to exchanges.
The report notes the attack could not be triggered by accident. It required hundreds of offers priced in a way no real trader would use, and no normal payment comes close to the values needed to cause an overflow. A secondary claim in the original report, that such offers could be used to block other users’ payments, was tested and found not to be a practical attack.
“We have found no evidence that this issue was exploited on any public network,” the XRPL disclosure said.
Discovery and Incident Timeline
The vulnerability was submitted through the XRPL Bug Bounty program on September 22, 2026, by researcher Cayden Liao and Veria AI, who also provided a proof of concept. The submission rated the finding as Major.
The incident response timeline shows that the RippleX engineering team, the developer arm of Ripple, reproduced the attack the same day on a local standalone server and in unit tests, confirmed the minted XRP could be spent, and raised the severity to critical. The fix was developed privately on September 22 and 23, merged into the first 3.4.1 release candidate on September 23, and released on September 25. On release day, more than 80% of validators on the default Unique Node List (UNL), the list of trusted validators most servers follow, were running 3.4.1 or later.
Why the Fix Skipped the Amendment Process
Changes to how the XRP Ledger processes transactions normally go through the amendment process. A new rule ships in the software switched off and activates only after it keeps support from more than 80% of trusted validators for two weeks.
This fix took effect on each server as soon as it upgraded. The report says this is the first time a change to transaction processing has deliberately shipped this way since the amendment system was introduced more than ten years ago. Because xrpld is open source, publishing the fix through the normal process would have exposed the bug for weeks while it remained exploitable on Mainnet.
The developers acknowledged the trade-off. During the upgrade window, an exploit attempt could have caused upgraded and older servers to disagree on the ledger, and in the worst case halt the network. The report judged a halt preferable to an incorrect ledger state that would be hard to roll back. The decision was made jointly by the XRPL Foundation, RippleX and XRPL validators, and the report stresses that it does not change how protocol changes are normally made. The source code for xrpld 3.4.1 was withheld at release and has now been published on GitHub.
Second Fix: Batch Transaction Wrapper Validation
The same release addressed a lower-severity flaw in the Batch feature, defined in the XLS-56 standard (XRP Ledger Standard 56). Batch lets one account submit up to eight transactions as a single unit. The specification requires each inner transaction to be wrapped in a field called RawTransaction, but the server did not enforce this.
The issue was first logged as finding F48 in the Sherlock Attackathon, a public security audit contest, and rated low severity. On September 18, 2026, Denis Angell of the XRPL Foundation confirmed that the earlier fix was incomplete. On September 22, Mayukha Vadari of RippleX found that the gap could cause servers running versions 3.3.0 and 3.4.0 to disagree on whether a transaction was valid, potentially stopping ledger validation.
At the time, the BatchV1_1 amendment held majority support and was scheduled to activate on September 29. Ripple and other validator operators switched their votes to “no” to reset its activation clock until a fix was ready. The fixBatchV1_2 amendment, shipped in 3.4.1, now rejects any Batch transaction that uses a different wrapper. Both fixBatchV1_2 and BatchV1_1 activated on Mainnet on October 9, 2026. No Batch amendment was active on Mainnet when the flaw was found, so no accounts or funds were affected. The original Batch amendment had been withdrawn earlier this year after a separate vulnerability was reported in February.
Why It Matters for XRP Holders
According to XRPL documentation, 100 billion XRP existed when the ledger was created, and the protocol’s rules do not allow new XRP to be issued. The overflow bug could have broken that core guarantee, though the practical risk on public networks was low given the deliberate setup the attack required.
The report places the finding within a layered security approach that RippleX outlined in June, combining independent audits, public attackathons, AI-assisted red teaming, fuzz testing and formal verification alongside the bug bounty. As a further step, every security finding marked as fixed will now be retested against each release candidate before it is closed.
What Node Operators Need to Do
All XRPL server operators must run xrpld 3.4.1 or newer to stay in sync with the network. With fixBatchV1_2 now active, older servers are amendment-blocked, meaning they can no longer process new ledgers until they upgrade. Security issues can be reported through the xrpld Security Policy.
Also Read: Ledger Confirms Hardware Implant Amid $86M Loss Probe, Urges Users to Re-Seed
