XRPL defends emergency fix for XRP overflow bug

The XRP Ledger released an emergency software fix after researchers found that a payment could create spendable XRP from an order book overflow, and developers say the normal amendment vote would have left the flaw exposed for weeks. The bug was in the payment engine, the software that calculates how much a buyer pays when a payment crosses offers on the ledger’s built-in exchange.

According to the XRPL vulnerability disclosure report, a researcher reported the flaw through the bug bounty program on Sept. 22. RippleX reproduced it, and the fix shipped in xrpld version 3.4.1 on Sept. 25. The report says XRPL Foundation members, RippleX, maintainers and validators agreed the risk justified a direct software change instead of waiting for an amendment vote.

How could an order book payment create new XRP?

A payment can consume multiple offers in an order book. The payment engine adds up the XRP owed across those offers, then charges the buyer that total. The bug was in that addition: it used a fixed-width integer without checking whether the sum had exceeded its maximum value.

When the number overflowed, it wrapped around to a small value, like an odometer rolling back after passing its last digit. The engine still paid each offer owner the full amount, but charged the buyer only the wrapped total. The gap became new XRP. The ledger’s invariant, a safety check meant to catch transactions that create XRP, used the same kind of sum and overflowed in the same way.

The attack required hundreds of specially priced offers and a payment designed to consume them all. XRPL says it could not happen through an ordinary trade, and investigators found no evidence it had been exploited on a public network.

Why did the fix skip the usual amendment vote?

Normally, protocol changes go through an amendment process in which validators vote, with a change taking effect after more than 80% support for two weeks. Developers said publishing the fix through that process would have revealed the vulnerability before the change took effect, giving attackers time to act.

The Cointelegraph report on the patch debate says XRPL developers also pushed back on claims that operators were forced to install the update. The official disclosure says more than 80% of default UNL validators were running version 3.4.1 or later on release day. The fix took effect when a server operator upgraded.

What changed in version 3.4.1?

The payment engine now checks for overflow when it adds amounts across offers and across multiple payment paths. If a total would overflow, that part of the payment fails with a “path dry” or “partial payment” result; it does not mint XRP. The report says the emergency decision was made for this severe bug, while transaction-processing changes continue to use amendments as the normal route.

Source material

• XRPL vulnerability disclosure report — xrpl.org
• Cointelegraph report on the patch debate — cointelegraph.com