The XRP Ledger has closed a critical integer-overflow vulnerability in its payment engine that had existed for roughly a decade and could have allowed an attacker to generate and spend new XRP in violation of the network’s fixed-supply rules.
According to the official vulnerability disclosure report published on October 9, 2026, the issue was identified through the XRPL bug bounty program and resolved in the emergency xrpld 3.4.1 software release.
The flaw involved how the ledger’s built-in decentralized exchange calculated totals when a single payment consumed many offers from the order book.
XRP amounts are handled as 64-bit integers.
When the sum of a large number of individual offer amounts exceeded the maximum value that a 64-bit integer can represent, the total wrapped around to a small number instead of triggering an error.
The payment engine still credited each offer owner the full amount specified in their offer, while charging the buyer only the wrapped total.
The difference appeared as newly created XRP that should never have existed.
An attacker could exploit this by creating a few hundred accounts and having each place an offer to sell a tiny quantity of another token in exchange for an extremely large quantity of XRP.
A single carefully constructed payment would then buy through all of those offers at once.
Existing safety checks failed to detect the problem.
The ledger’s invariant that verifies no transaction creates XRP used the same 64-bit arithmetic and therefore wrapped identically, so the net change looked normal.
A separate per-account balance limit, which rejects balances exceeding the total intended XRP supply, was also bypassed because the newly created tokens were distributed across hundreds of accounts.
The attack required only a few hundred XRP for account and offer reserves—most of which could later be recovered—plus ordinary transaction fees.
It could not occur accidentally, because normal trading activity never produces offer totals large enough to overflow a 64-bit integer.
If successfully executed and validated, the resulting XRP would have been fully spendable and transferable, potentially far exceeding the network’s intended maximum supply of 100 billion tokens in a single transaction.Researchers Cayden Liao and Veria AI reported the issue on September 22, 2026.
RippleX engineers quickly reproduced the behavior on a standalone server, confirmed that the newly created XRP could be spent in a subsequent transaction, and classified the severity as critical.
The fix was included in xrpld 3.4.1, released on September 25.
The updated software adds overflow checks when summing amounts across offers; if an overflow would occur, the affected portion of the payment fails cleanly.
The “no XRP created” invariant was also strengthened with a wider counter that cannot wrap.
Because of the severity and the fact that the open-source nature of the code would have made the bug publicly known for weeks under the normal amendment process, the change took effect immediately upon upgrade rather than waiting for the standard two-week validator voting period.
More than 80 percent of default UNL validators upgraded on the day of release.
The disclosure states that no evidence was found of the vulnerability being exploited on any public network.
The same software release also addressed a separate validation issue related to the Batch transaction feature, which was remediated through an amendment that activated on October 9.
The episode highlights both the long dormancy of certain edge-case bugs in mature blockchain codebases and the value of structured bug-bounty programs, audits, and rapid coordinated response among developers and validators. With the patch now deployed and widely adopted, the network’s supply integrity remains intact.