XRP Ledger defends bypass of its amendment process for emergency patch

XRP Ledger developers defended their decision to patch a flaw that could create spendable XRP without waiting for the network’s usual validator vote, saying the delay could have left the vulnerability open for weeks. In its Oct. 12 report, Cointelegraph’s account of the Foundation’s response said the XRPL Foundation disputed claims that the update was forced on operators. The episode tests how the network handles a severe security flaw when its normal governance process could also expose users to risk.

How could the payment bug create XRP?

The flaw was an integer overflow in the payment engine, present since 2015, according to the XRPL project’s vulnerability disclosure report, published Oct. 9. It affected xrpld 3.4.0 and earlier. When one payment consumed hundreds of specially priced offers, the engine added up the XRP owed using a 64-bit integer. If the sum exceeded that integer’s maximum, it wrapped around to a much smaller number instead of failing.

The engine could then credit each offer owner the full amount while charging the buyer only the wrapped total. The gap would become newly created XRP that could be spent or transferred. The report says the researcher disclosed the issue through the XRPL Bug Bounty program on Sept. 22. RippleX reproduced it on a standalone server and confirmed the minted XRP could be spent in a follow-up payment. Developers said they found no evidence of exploitation on a public network.

The attack required deliberate setup: hundreds of offers priced far outside normal trading, followed by a payment designed to consume them together. The report says it would have required only a few hundred XRP in account and offer reserves, plus transaction fees; the large XRP amounts were what the offer owners would receive. Normal trades would not reach the overflow.

Why skip the usual validator vote?

The fix shipped in xrpld 3.4.1 on Sept. 25 and took effect on each server when its operator upgraded. Under the normal amendment process, a rule change is included in software but remains inactive until it has support from more than 80% of trusted validators for two weeks. That process coordinates a change so validators apply the new rule at the same ledger.

For this flaw, the XRPL report says that waiting would have made the fix public while the vulnerability remained exploitable through the upgrade period and vote. But the direct patch brought a different risk: upgraded and older servers could process an exploit payment differently, potentially splitting ledger results or halting validation. More than 80% of default UNL validators were running 3.4.1 or later on release day, the report says, reducing the time the network spent exposed to that mixed-version risk.

The report says the Foundation, RippleX and validators agreed the danger of creating XRP that would be hard to remove outweighed the risk of a short upgrade window. The Foundation also said, as reported by Cointelegraph, that no single party made the decision alone and operators remained free to choose their software. The patch was a departure from the amendment process for transaction changes, which the project says remains the normal route.

What should XRPL operators and users watch next?

The first signal is whether server operators have upgraded to 3.4.1 or newer. The report says older servers are now amendment blocked after a separate amendment activated on Oct. 9, and that the source code for 3.4.1 has since been published. It also says the fix adds overflow checks to payment calculations and uses a wider counter in the “no XRP created” safety check, so that the check itself cannot wrap in the same way.

The second signal is how the project applies its stated security changes: it plans to retest every finding marked fixed against the release candidate before closing it. That would address a weakness exposed here: two safeguards missed the overflow because both relied on arithmetic that could wrap. Whether that added verification becomes routine, and whether future emergency fixes can be coordinated as quickly, will shape how XRPL balances rapid response with its validator-led rule changes.

Source material

• Cointelegraph’s account of the Foundation’s response — cointelegraph.com
• XRPL project’s vulnerability disclosure report — xrpl.org