XRP Ledger Fixes Critical Overflow Bug That Could Create New XRP

XRP Ledger maintainers have disclosed and fixed a critical payment-engine vulnerability that could have created spendable XRP from nothing. The patch shipped in xrpld 3.4.1, released on September 25, 2026. A public disclosure published October 9 says investigators found no evidence that the issue was exploited on any public network.

What the vulnerability could do

The flaw involved unchecked 64-bit integer addition in the payment engine. A deliberately constructed payment could consume hundreds of unusual order-book offers whose individual XRP amounts were valid but whose combined total exceeded the integer limit. The sum could then wrap to a small number.

In that scenario, offer owners would receive the full amounts specified by their offers while the buyer would be charged only the wrapped total. The difference would become newly created, spendable XRP. Maintainers said the attack could be prepared with a few hundred XRP in refundable account and offer reserves, plus transaction fees.

Readers following the asset can check the verified XRP/USDT spot market and XRPUSDT perpetual market on OrangeX.com.

Why existing checks did not stop it

XRPL already had an invariant designed to ensure that a transaction cannot create XRP. However, that check summed balance changes using the same type of 64-bit counter, so it could overflow in the same way and mistakenly see only an ordinary transaction fee. A separate per-account balance check also would not catch the issue because the newly created XRP could be spread across hundreds of accounts, with each balance remaining below the network’s total-supply limit.

Maintainers traced the vulnerable payment-engine logic to 2015. Normal trading could not accidentally reach the code path: the exploit required hundreds of offers priced in a way ordinary traders would not use, followed by a specially built payment that consumed them together.

What changed in xrpld 3.4.1

Version 3.4.1 now checks for overflow while totaling amounts across offers and while combining results from multiple payment paths. If the total would overflow, the path fails cleanly and no XRP is created. The “no XRP created” invariant now uses a wider counter, and several other balance-aggregation paths were hardened as a precaution.

The fix took effect as soon as a server upgraded rather than waiting for the usual amendment process. Maintainers said the severity justified the decision because publishing a dormant amendment would have exposed the exploit while leaving it usable during the voting and activation period. More than 80% of validators on the default trusted list were running the protected version on September 25.

Server operators must use xrpld 3.4.1 or newer. The same release also contains a separate Batch transaction fix whose amendment activated on October 9, leaving older servers amendment-blocked. For broader coverage, see OrangeX.com Crypto News and review the OrangeX.com Trust Center for official security resources.

OrangeX.com Analysis

The immediate takeaway is operational: the publicly described minting path has been closed, and maintainers report no detected exploitation. The episode still matters because it shows how the same arithmetic assumption can defeat both business logic and a safety invariant. The added wider counter provides an independent backstop, which is more valuable than a single-path patch.

The remaining uncertainty is evidentiary rather than technical. “No evidence of exploitation” is not identical to proof that exploitation was impossible, although the highly artificial transaction pattern should make historical review more practical. Watch for any follow-up audit results and for operators’ continued adoption of supported releases. This analysis does not imply a direction for XRP’s market price.