XRP Ledger Fixed a Bug From 2015 That Could Have Created…

The XRP Ledger fixed a decade-old software flaw that could have allowed an attacker to create spendable XRP without funding it, bypassing one of the network's most basic monetary rules: no more than the original 100 billion XRP are supposed to exist.The vulnerability was reported on September 22 by researcher Cayden Liao and Veria AI through the XRPL bug bounty program. RippleX engineers reproduced the attack that day, confirmed that the newly created XRP could be spent in a later transaction and raised the issue from major to critical severity.The fix was shipped three days later in xrpld 3.4.1 on September 25. The full vulnerability was not publicly disclosed until October 9.According to the XRP Ledger's disclosure report, developers have "found no evidence that this issue was exploited on any public network."

Hundreds of Offers and One Payment Could Create New XRP

The flaw sat inside the XRP Ledger's payment engine and its built-in decentralized exchange.An attacker could create a few hundred accounts and have each account place an offer selling a very small quantity of another token in exchange for an unusually large amount of XRP. Each individual offer was valid on its own.The attacker could then send one specially constructed payment that consumed all of those offers at once.The problem appeared when the payment engine calculated the total amount of XRP the buyer owed. XRP amounts were being added using a 64-bit integer. Once the combined value became larger than that integer could hold, the number wrapped around to a very small value instead of producing an error.The engine still credited every seller with the full XRP amount specified in its offer, but charged the buyer only the overflowed total.The difference was XRP that had not existed before.RippleX said the attack did not require an attacker to own anything close to the amount being created. The practical upfront cost was only a few hundred XRP needed for account and offer reserves, most of which could later be recovered when those ledger objects were removed, plus ordinary transaction fees.The attack also could not occur accidentally. It required hundreds of deliberately mispriced offers and a payment specifically constructed to consume them together.

The Safety Check Could Have Missed the Mint as Well

The more unusual part of the vulnerability is that the XRP Ledger already had a safety mechanism designed specifically to stop a transaction from creating XRP.That invariant did not solve the problem.The post-transaction check calculated the net XRP balance change using the same type of 64-bit arithmetic. If the payment-engine calculation overflowed, the safety check could overflow in the same way.The result could therefore make it appear that the only XRP destroyed or created during the transaction was the normal transaction fee, even though hundreds of attacker-controlled accounts had received new XRP.A second protection also failed to close the path. The ledger rejects a balance if one individual account ends up holding more than the total XRP supply. By distributing the newly created XRP across hundreds of accounts, an attacker could keep each individual balance below that limit.XRPL's investigation says the underlying overflow appears to have existed since the current payment engine was written in 2015. The "no XRP created" invariant was added roughly two years later but inherited the same arithmetic weakness.

XRPL Fixed It on September 25 and Explained It on October 9

The disclosure also explains why the September 25 release gave operators little detail about what they were installing.Version 3.4.1 was announced as an emergency release for "security-sensitive issues." Its public changelog referred to "assorted integer-arithmetic hardening in the payment engine and ledger helpers," but did not disclose that the underlying vulnerability could mint spendable XRP.The source code containing the fix was also temporarily withheld.RippleX says that was deliberate. Publishing the patch while leaving the normal two-week amendment process running would have shown attackers exactly where the flaw was while much of the network remained vulnerable.The overflow correction therefore did not go through the normal amendment process. It took effect on each server as soon as that server installed 3.4.1. XRPL says this was the first time in more than a decade that a transaction-processing change had intentionally been deployed that way.More than 80% of validators on the default Unique Node List had upgraded to 3.4.1 by September 25, according to the disclosure. The complete technical report and source code were made public after the network had been protected.The emergency release was already attracting attention before the disclosure. FinanceFeeds reported that validators reset the XRP Ledger's Batch activation schedule after xrpld 3.4.1 introduced a security-sensitive fix, pushing that upgrade from September 29 to October 9.FinanceFeeds also tracked Permission Delegation and the accompanying October 8-9 amendment timetable as validators prepared the network for the new software.

Node Operators Should Be on xrpld 3.4.1 or Later

The overflow itself was fixed immediately when a server installed xrpld 3.4.1. Separately, the fixBatchV1_2 amendment contained in the same emergency release activated on Mainnet on October 9.That means operators still running older versions are now amendment-blocked and cannot remain synchronized with the network. XRPL's current instruction is for all server operators to use 3.4.1 or newer.The fixed-supply rule itself has not changed. XRP Ledger documentation says all 100 billion XRP were created when the network was launched in 2012 and that no additional XRP should be creatable under the protocol.The significance of the September bug is that, for roughly a decade, there was a deliberately reachable path around that rule—and the ledger's own check designed to detect newly created XRP could have made the same arithmetic mistake as the vulnerable transaction.