The XRP Ledger (XRPL) development team disclosed an integer-overflow flaw on October 9 that could, under carefully constructed conditions, have allowed spendable XRP to be created out of nothing. The fix shipped in xrpld version 3.4.1 on September 25, roughly two weeks ahead of the public disclosure, and the team reported finding no evidence that the vulnerability was ever exploited on a public network.

The details were laid out in XRPL's October 9 vulnerability disclosure report.

A payment calculation that could produce XRP from nothing

The report describes an integer-overflow flaw in the ledger's payment engine. Under carefully constructed conditions, a payment that consumed many order-book offers could have credited accounts with XRP that the sender had not actually paid. Order books are a native XRPL structure, part of the ledger's built-in exchange, so the flawed arithmetic sits in code that underpins trading on the ledger as well as payments.

Each individual offer in the transaction could appear valid on its own. The failure arose when the engine added the XRP amounts across all of them. Once the total exceeded the maximum size of the number used for that calculation, it could wrap around to a much smaller value instead of producing an error.

In that scenario, the engine would still credit the offer owners with their full XRP amounts while charging the buyer only the wrapped-around total. The difference represented newly created XRP, which could then be moved, traded, or sent to an exchange like any other balance.

Why the flaw was serious

The attack did not require a large XRP balance. An attacker could have controlled the accounts placing the offers, paid the necessary account reserves and transaction fees, and then spread the created XRP across those accounts.

The vulnerability sat in payment arithmetic rather than wallet access, leaving account keys unaffected. Triggering it required hundreds of deliberately priced offers and a transaction designed to consume them together; an ordinary XRP payment or trade would not approach the values needed to create the overflow.

For a ledger, few defects are as sensitive as one that can mint spendable units, because every balance depends on new XRP entering circulation only through the network's defined rules.

XRPL said it found no evidence of exploitation on a public network, and no private-key compromise, loss of funds, or consensus failure was reported. The flaw appears to have been present since the current payment engine was written in 2015, remaining undiscovered because normal activity never reached the arithmetic limit.

The ledger's existing protection against newly created XRP also relied on the same kind of addition. It could wrap around in the same way as the payment engine, allowing the transaction to appear instead of flagging the unexpected increase in balances.

Why developers used an emergency deployment

Developers released the overflow fix before publishing its technical details because a normal amendment timeline would have left a known exploit available for weeks. The patch shipped in xrpld version 3.4.1 on September 25, while the public disclosure followed on October 9.

XRPL usually changes transaction rules through amendments. Validators first upgrade their software, then maintain the required support for a set period before the new rule activates at the same ledger point across the network. That process avoids situations in which different servers reach different conclusions about the same transaction.

Waiting for that process would have created a difficult problem in this case. Because xrpld is open source, publishing the repair could have shown attackers where to look while older software still accepted the vulnerable transaction path. The team therefore made the new overflow check take effect when an individual server upgraded.

That faster approach carried a temporary compatibility risk: an unpatched server could have accepted an exploit transaction that an upgraded server rejected. Developers considered that less dangerous than allowing created XRP to enter the market. According to the report, more than 80% of validators on the default UNL had upgraded on the day version 3.4.1 was released.

The disclosure covered a second, separate flaw

The report also detailed a validation problem in XRPL's forthcoming Batch feature, which lets users submit several transactions as one unit. The flaw could have caused servers running different versions of the software to disagree over a malformed Batch transaction, interrupting ledger validation or breaking applications that parse transaction data.

The Batch flaw was caught before the feature reached mainnet. The overflow issue, by contrast, affected existing payment-engine code, which is why its patch could not wait for a standard activation cycle. With the feature itself still forthcoming, its arrival on mainnet with the validation fix already in place is the part of this disclosure that remains ahead.

The report arrived while XRPL was also activating new account-control tools for businesses. The changes address different parts of the ledger, yet both depend on node operators, wallet providers, and developers following the same current rules.

What users and operators need to do

Regular XRP holders do not need to move funds, replace a wallet, or exchange their tokens. The update concerns the software that validates transactions, not account balances, wallet keys, or the XRP supply held by users.

• XRP holders: No action is required.
• Exchange users: Follow platform notices if an exchange carries out maintenance on its own XRPL.
• Node operators: Upgrade to xrpld 3.4.1 or later to remain in sync with the network. Older servers are now amendment-blocked following the activation of the Batch fix, meaning they cannot continue following the current ledger rules until they update.

The fix protected XRP's supply rules before they were tested

The disclosure shows how close the ledger came to a supply-integrity failure and why validators moved quickly. The flaw was fixed before its details became public, no exploit was found, and the payment engine now uses checks designed to stop the same class of arithmetic error before it reaches a validated ledger. What remains to be seen from outside is how quickly the rest of the network converges on xrpld 3.4.1 or later, given that unpatched servers are already amendment-blocked from following the current ledger.

This article is for informational purposes only and does not constitute investment or technical advice. Node operators should review current XRPL release documentation before updating production infrastructure.

This article is based on reporting originally published by Coindoo.