XRPL Discloses Critical Bug That Could Have Created New XRP

Critical Vulnerabilities Disclosed on XRP Ledger, Including Potential for Unauthorized XRP Creation

San Francisco, CA – October 9, 2026 – The XRP Ledger (XRPL) has disclosed two significant software vulnerabilities, one of which could have allowed attackers to create new, spendable XRP. The other flaw impacted the network’s Batch transaction functionality, potentially disrupting transaction validation.

Payment Engine Bug Could Have Led to XRP Inflation

According to an official report, a critical bug within the XRPL’s payment engine was identified and subsequently fixed in version 3.4.1 of the xrpld software, released on September 25. The XRPL has reported no evidence that this vulnerability was exploited on any public network.

The vulnerability stemmed from how the payment engine calculated the XRP required to complete trades across multiple offers within an order book. A calculation overflow could occur if the combined amount exceeded the system’s maximum supported value. This could have resulted in the payment engine charging a buyer less XRP than what was credited to offer owners, effectively generating new XRP.

Exploiting this bug would have required a meticulously crafted order book featuring hundreds of offers with exceptionally high prices, followed by a specific payment transaction. The report clarifies that ordinary payments or trades could not trigger this vulnerability.

A researcher brought the issue to light through the XRPL Bug Bounty program on September 22. The RippleX engineering team successfully reproduced the bug and confirmed that any XRP generated through this flaw would have been spendable.

The fix, implemented in version 3.4.1, includes enhanced checks to prevent calculation overflows and strengthened safeguards against unauthorized XRP creation.

Batch Transaction Flaw Threatened Network Consensus

The second vulnerability affected the XRP Ledger’s Batch transaction feature, which enables users to submit multiple transactions simultaneously. The flaw allowed a transaction within a batch to utilize an incorrectly structured field, yet the server would still accept and process it.

This posed a risk of differing XRPL software versions disagreeing on the validity of a transaction, potentially preventing validators from reaching consensus and interrupting ledger validation.

The report states that this issue did not grant attackers the ability to bypass transaction signatures or directly steal funds.

XRPL addressed this flaw through the fixBatchV1_2 amendment, which mandates the correct structure for transactions. As the Batch feature had not been activated on the mainnet at the time of the vulnerability’s discovery, no mainnet accounts or funds were identified as being affected by this bug.

XRPL developers and validator operators temporarily withdrew support for the original Batch amendment to reset its activation timeline while the fix was prepared. The corrected amendment subsequently gained support and was activated on the mainnet on October 9, coinciding with the publication of the vulnerability report.

Enhanced Security Testing and Future Measures

The report also detailed an adjustment to the security testing process. XRPL intends to retest reported vulnerabilities against release candidates to ensure fixes are effective before software releases.

Both vulnerabilities have now been resolved. The XRPL reiterates that there is no evidence the critical payment engine bug was exploited on a public network, nor does the report indicate that either flaw resulted in actual fund loss or an increase in XRP supply. The payment engine fix is integrated into xrpld version 3.4.1, while the Batch transaction issue was resolved via the fixBatchV1_2 amendment.

The report does not advise XRP holders to move their funds or alter their private keys. The software upgrade is primarily relevant for XRPL server operators who require compatible versions to maintain synchronization with the network.