XRP Ledger fixes bug that could have minted trillions
XRPL says its 3.4.1 update fixed a payment overflow that could create spendable XRP, and developers found no evidence of exploitation on public networks.
The Blockheight Editors··2 min read
The XRP Ledger fixed a payment-engine flaw in its xrpld 3.4.1 release on Sept. 25 that could have let an attacker create spendable XRP, according to the XRPL vulnerability disclosure report published Oct. 9. The report says the bug may have been in the code since 2015 and that developers found no evidence it was exploited on a public network.
How could the flaw create new XRP?
A payment that consumed many order-book offers could make the engine’s total overflow, XRPL said. The calculation used 64-bit integer addition without an overflow check, so a sum above the maximum wrapped to a small number: offer owners received their full amounts while the buyer was charged only the wrapped total.
The ledger’s “no XRP created” safety check used similar arithmetic and wrapped in the same way, the report said. An attacker could spread the resulting XRP across hundreds of accounts, keeping each balance below the individual account limit.
How much XRP could one transaction have created?
Veria Labs co-founder Cayden Liao estimated that one exploit transaction could have created about 18 trillion XRP, 184 times the 100 billion XRP issued at launch, The Block reported. XRPL’s report confirms the flaw could create spendable XRP beyond the total supply, but does not give that estimate.
The attack required hundreds of deliberately mispriced offers followed by one payment designed to consume them, according to XRPL. The report says normal payments and trades would not reach the overflow.
What changed, and what happens next?
Version 3.4.1 added overflow checks when summing offers and a wider counter for the “no XRP created” safety check, XRPL said. The fix took effect as each server upgraded, without the usual amendment vote, because the normal process could have left the vulnerability visible and exploitable for weeks.
More than 80% of validators on the default Unique Node List were running 3.4.1 or later on release day, the report said. XRPL says server operators must upgrade to 3.4.1 or newer to stay in sync; it has found no evidence the flaw was exploited on a public network.
Source material
- XRPL vulnerability disclosure report published Oct. 9 — xrpl.org
- The Block reported — theblock.co