Skip to the article
Blockheight

Crypto markets, protocols, policy

XRP Ledger discloses flaw that could mint spendable XRP

XRPL's September 25 release fixed a payment overflow that could mint spendable XRP; RippleX says it found no evidence the flaw was used on public networks.

The Blockheight Editors··2 min read

XRP Ledger discloses flaw that could mint spendable XRP

XRP Ledger developers disclosed on Oct. 9 that a payment bug fixed in September could have created spendable XRP beyond the ledger’s intended supply, according to the XRPL vulnerability disclosure report. The flaw was reported on Sept. 22 by researcher Cayden Liao and Veria AI; RippleX reproduced it and said it found no evidence of exploitation on public networks.

How could one payment create new XRP?

The payment engine could add up XRP owed across many order-book offers until its counter overflowed and wrapped to a small number, the report says. The offer owners would receive their full amounts while the buyer was charged only the wrapped total, creating XRP that should not exist.

An attacker could arrange hundreds of accounts with offers to exchange small amounts of another token for unusually large amounts of XRP, then use one payment to take those offers together. The ledger’s safeguard against creating XRP used the same miscounted total, so it could miss the excess; spreading receipts across accounts also avoided a per-account limit, according to the CoinDesk report.

What did the XRPL patch change?

The fix shipped in xrpld 3.4.1 on Sept. 25, before the public disclosure. The software now checks for overflow when it totals offers and rejects a payment if the sum would exceed the limit; the “no XRP created” check also uses a wider counter that cannot wrap around, the XRPL report says.

The XRPL Foundation report says the fix took effect as servers upgraded, without the usual validator amendment process. More than 80% of default UNL validators were running 3.4.1 on release day, it says.

What happens next for XRPL operators?

All server operators must upgrade to 3.4.1 or newer to stay in sync with the network, according to the report. Developers said they found no evidence the overflow was exploited on a public network; whether anyone attempted it privately remains unconfirmed.

Source material

Related stories