XRP Ledger (XRPL) patched a decade-old overflow flaw that could have created spendable XRP beyond the 100 billion supply cap, with no evidence of Mainnet exploitation.
The XRP Ledger has patched a critical flaw that could have allowed a deliberately constructed payment to create spendable XRP beyond the network’s fixed supply.
The bug had apparently been sitting inside XRPL’s payment engine since 2015 before researchers uncovered it through the network’s bug bounty program.
The issue was reported on Sept. 22 and fixed three days later in xrpld 3.4.1, an emergency release.
RippleX engineers reproduced the exploit on a standalone server and confirmed that the newly created XRP could subsequently be spent.
Importantly, the investigation found no evidence that the vulnerability was ever exploited on XRPL Mainnet or another public network.
XRP was created with a maximum supply of 100 billion, and XRPL rules are designed so no additional XRP can be minted.
How the XRP Creation Bug Worked
The flaw involved payments that consumed large numbers of offers from XRPL’s built-in order book.
An attacker could create hundreds of accounts and have each one offer a tiny amount of another token in exchange for an unusually large amount of XRP.
A specially constructed payment could then sweep through all those offers at once.
The payment engine used a 64-bit integer to add up how much XRP the buyer owed. With enough extreme offers, the total could exceed the maximum value the counter could hold.
Rather than rejecting the calculation, the number wrapped around to a tiny value.
The offer accounts would still receive their full XRP amounts, while the buying account would be charged only the wrapped total. The difference effectively became new XRP that had never existed before.
The attack was also relatively inexpensive. The official disclosure says it required only a few hundred XRP for account and offer reserves, much of which could later be recovered, plus normal transaction fees.
XRPL’s Safety Check Could Have Missed the Mint
XRPL already had an invariant designed specifically to prevent transactions from creating XRP.
However, that check used similar arithmetic when adding balance changes. It could therefore overflow in the same way, making the fraudulent transaction appear normal.
Another protection limits individual account balances, but spreading the newly created XRP across hundreds of accounts kept each balance below the threshold.
The bug could not occur through ordinary trading. It required hundreds of intentionally abnormal offers and a payment specifically designed to consume them together.
Emergency Fix Skipped the Normal Amendment Process
The response was unusual for XRPL.
Protocol changes normally go through the amendment system, requiring more than 80% validator support for two weeks before activation.
For this vulnerability, developers decided that waiting would create a larger risk because releasing the fix would also reveal where the exploit existed.
Instead, the correction became effective as individual servers upgraded to xrpld 3.4.1. XRPL says this was the first deliberate change to transaction processing shipped this way since the amendment system was introduced more than a decade ago.
Validators moved quickly. More than 80% of validators on the default UNL were running version 3.4.1 or later on Sept. 25, the same day the emergency release became available.
The fix now checks calculations for overflow before totals are accepted. XRPL also widened the counter used by its “no XRP created” invariant, providing another safeguard against similar arithmetic failures.
The full details were withheld until Oct. 9, after the network had been protected. The disclosure credits Cayden Liao and Veria AI with finding the vulnerability and submitting the proof of concept.
Be the first to comment