XRP Ledger fixes decade-old flaw that could mint new XRP

The XRP Ledger fixed a payment-engine flaw in its Sept. 25 software release that could have created spendable XRP beyond the network’s 100 billion supply cap, according to the XRP Ledger’s Oct. 9 vulnerability report. The developers said they found no evidence the bug had been exploited on a public network.

The issue was reported through the XRPL Bug Bounty program on Sept. 22. RippleX engineers reproduced the attack on a standalone server and confirmed the newly created XRP could be spent in a later payment, the report said.

How could one payment create new XRP?

A payment could consume hundreds of specially priced offers, causing a 64-bit integer total to overflow and wrap around to a small number. The ledger would credit each offer owner the full XRP amount but charge the buyer only the wrapped total, according to the report.

The ledger’s “no XRP created” safety check used the same kind of arithmetic and also wrapped around, so it missed the excess. By spreading the XRP across hundreds of accounts, an attacker could also avoid the per-account balance limit, developers said.

The offers had to be deliberately constructed and priced far outside normal trading. The report said the attack would have required only a few hundred XRP in account and offer reserves, most of which could be recovered, plus transaction fees.

When was the flaw fixed, and was it exploited?

The overflow fix shipped in xrpld 3.4.1 on Sept. 25, and the vulnerability report said there was no evidence of exploitation on public networks. CoinDesk’s report also said RippleX found no evidence the flaw had been exploited.

The patch checks for overflow when summing amounts across offers and fails the affected payment cleanly. Developers also changed the “no XRP created” check to use a wider counter that cannot wrap around, the XRPL report said.

Why did the patch bypass the amendment process?

The fix took effect on each server as soon as it upgraded, instead of waiting for the XRP Ledger’s usual validator-vote process. The report said developers judged that route safer because the open-source release would reveal the fix while unpatched servers remained vulnerable during a longer activation period.

That choice carried a risk: during the upgrade window, servers on different versions could process an exploit payment differently and disagree on the ledger. XRPL developers said they considered that risk preferable to leaving the flaw exploitable while the amendment process ran.

Sources

• XRP Ledger’s Oct. 9 vulnerability report — xrpl.org
• CoinDesk’s report — coindesk.com