XRP Ledger fixes flaw that could mint spendable XRP

The XRP Ledger fixed a payment-engine flaw that could have created spendable XRP through a deliberately crafted payment, putting its fixed supply at risk. The bug appears to have been present since 2015, according to the XRPL’s vulnerability disclosure report.

The flaw could have let an attacker create XRP that could be moved or traded, while the network’s safety checks failed to catch it.

How could a payment create XRP?

The exploit used the XRP Ledger’s built-in order book, where users post offers to exchange one asset for another. An attacker could create hundreds of accounts, each posting an offer for a tiny amount of a token in return for a very large amount of XRP, then send one payment that consumed all those offers.

The payment engine added up the XRP owed using a fixed-size 64-bit integer. When the total exceeded what that number could hold, it wrapped around to a small value instead of returning an error. The engine credited each offer owner the full amount but charged the buyer only the wrapped total, creating a difference in XRP.

The ledger’s “no XRP created” safety check used the same kind of arithmetic, so it also wrapped around and did not flag the transaction. Splitting the XRP across hundreds of accounts kept each account below the separate balance limit. RippleX reproduced the exploit on a standalone server and confirmed the XRP could be spent in a later payment, CoinDesk reported.

Was the bug used on the public network?

XRPL says it found no evidence that the flaw was exploited on any public network. Its report says the attack required specially priced offers that no real trader would use, followed by a payment built to consume them together; normal payments would not reach the overflow.

The attack did not require a large starting balance. The report estimates it would take a few hundred XRP for account and offer reserves, which could be recovered when the objects were removed, plus ordinary transaction fees. It says the exploit could not happen by accident.

What changed for XRPL operators?

The fix shipped in xrpld version 3.4.1 on Sept. 25. The payment engine now checks for overflow when adding amounts across offers and rejects a payment path that would exceed the limit; the “no XRP created” check also uses a wider counter.

This payment fix took effect as each server upgraded, rather than waiting for the XRP Ledger’s usual amendment process. XRPL said that choice shortened the time a publicly disclosed flaw would remain exploitable, but meant upgraded and older servers could process an exploit attempt differently during the upgrade window.

XRPL says all server operators must upgrade to 3.4.1 or newer to stay in sync with the network. For people making ordinary payments or trades, the report says the fix does not change normal transaction results.

Sources

• XRPL’s vulnerability disclosure report — xrpl.org