XRP Ledger patched flaw that could create spendable XRP

The XRP Ledger’s developers fixed a payment-engine flaw that could let an attacker create spendable XRP through the built-in exchange, threatening the ledger’s fixed supply. The XRPL project’s vulnerability report says researcher Cayden Liao and Veria AI reported the bug through its bounty program on Sept. 22; RippleX engineers reproduced it and confirmed the newly created XRP could be spent in a later payment.

How could one payment create new XRP?

The attack relied on how the payment engine adds up many order-book offers. First, an attacker could create hundreds of accounts and have each post an offer selling a tiny amount of a token for a very large amount of XRP. Each offer was valid on its own. Then a payment from another account could consume all those offers at once.

The engine credited each seller the full XRP amount in its offer, but used unchecked 64-bit addition to calculate what the buyer owed. Once the total exceeded the number that arithmetic could represent, it wrapped around to a small amount. The buyer therefore paid only that smaller total, while the offer owners received much more XRP than had been spent.

Why didn’t the ledger’s safety checks stop it?

The ledger checks that transactions do not create XRP, but the check used the same kind of arithmetic and wrapped around in the same way. The report says that made the transaction appear to create no XRP. A separate per-account limit also did not catch it: the attacker could spread the new XRP across hundreds of accounts, keeping each balance below the limit.

This required a deliberately constructed payment and hundreds of offers priced far outside normal trading. XRPL says ordinary payments would not reach the overflow, and testing found the offers would sit below real liquidity in the order book. The project reported no evidence the flaw was exploited on a public network.

What changed in the patch?

The fix shipped in xrpld version 3.4.1 on Sept. 25. The software now checks whether adding offer amounts would overflow and fails that part of the payment cleanly if it would. Developers also changed the no-new-XRP safety check to use a wider counter that cannot wrap around in the same way.

CoinDesk’s report said the vulnerability likely dated to 2015, when the current payment engine was written. According to XRPL, the fix took effect on each server as it upgraded, rather than waiting for the ledger’s usual amendment process. The immediate change was a new overflow check; the next thing to watch is whether operators keep their servers on version 3.4.1 or later.

References

• XRPL project’s vulnerability report — xrpl.org
• CoinDesk’s report — coindesk.com