XRP Ledger fixes flaw that could have breached 100B cap

XRP Ledger developers disclosed on Oct. 9 that a decade-old bug could have allowed attackers to create spendable XRP and exceed the network’s 100 billion-token supply cap. RippleX fixed the flaw in the xrpld 3.4.1 release on Sept. 25 and found no evidence that it had been exploited on a public network.

Researcher Cayden Liao and Veria AI reported the bug through the XRPL bug bounty program on Sept. 22. RippleX engineers reproduced the attack on a standalone server, confirmed that the newly created XRP could be spent in a later transaction and raised the vulnerability’s severity rating from major to critical.

The flaw affected the payment engine’s handling of trades involving many offers on the ledger’s built-in exchange. When a payment used several hundred offers that each required a large amount of XRP, the software added the buyer’s obligations with a 64-bit integer without checking whether the total was too large.

If the total exceeded the number’s maximum value, it wrapped around to a much smaller amount. The owners of the offers received full payment, while the buyer was charged only the reduced total. This left newly created XRP in accounts controlled by the attacker.

Two safeguards failed to detect the transaction. The ledger’s “no XRP created” check used the same calculation and produced the same overflowed result. A separate account-balance check could identify an account holding more XRP than the total supply, but the attacker could spread the newly created tokens across hundreds of accounts.

RippleX did not use the XRP Ledger’s standard amendment process to deploy the fix. Under that process, a new transaction rule remains inactive until more than 80% of trusted validators support it for two weeks. Developers bypassed the process because publishing the fix while the code remained exploitable could have exposed the public network for weeks.

The approach carried a risk that different software versions could cause the network to halt. Ordinary transactions did not reach the vulnerable code path, however. More than 80% of validators on the default Unique Node List were running version 3.4.1 on the day of its release, before the updated source code was published.

The flaw had existed since the current payment engine was developed in 2015. All 100 billion XRP were created when the ledger launched in 2012, and transaction processing is not intended to create additional tokens.

The same release fixed a separate validation flaw involving the Batch transaction wrapper. That fix was activated on the XRP Ledger mainnet on Oct. 9. RippleX is adding a second verification step so security fixes are tested again against the final release candidate.