uMaHF0G5M1jYL9t88qHEEkQggU6GJ5wTZlhvItt7
Bookmark

XRP Ledger Bug Could Have Enabled Unlimited XRP Creation, Developers Say

XRP Ledger developers disclosed an integer overflow flaw that could enable unauthorized XRP creation, prompting an emergency xrpld 3.4.1 update.

XRP Ledger security vulnerability involving payment calculations, potential unauthorized XRP creation and the emergency xrpld 3.4.1 update.

A critical vulnerability in the XRP Ledger's payment engine could have allowed attackers to create unauthorized, spendable XRP through a specially constructed transaction, according to a security disclosure published by XRPL developers on October 9. The flaw affected xrpld version 3.4.0 and earlier releases and was addressed through the emergency xrpld 3.4.1 update released on September 25.

The vulnerability stemmed from an integer overflow error that could undermine calculations used to process payments and enforce XRP supply protections. Developers said the issue could have enabled attackers to pay substantially less than the amount required for certain transactions while sellers still received their full XRP payments, potentially creating unauthorized tokens in the process.

Despite the severity of the flaw, investigators found no evidence that it had been exploited on any public XRP Ledger network. The disclosure also detailed a separate validation error involving the Batch inner transaction wrapper, which was addressed through the same emergency update.

How the XRP Ledger Vulnerability Could Have Created Unauthorized XRP

The payment engine flaw was reported by a security researcher through the XRPL Bug Bounty program on September 22. The researcher demonstrated that specially constructed trading offers could trigger incorrect calculations when a payment consumed multiple orders from the ledger's order books.

Under normal conditions, According to the disclosure, the payment engine determines the total XRP needed to complete a transaction involving several offers. In the vulnerable implementation, certain calculations could exceed the permitted integer range, causing the resulting value to reset unexpectedly rather than reflect the correct amount.

This calculation error created a potential mismatch between the payment received by sellers and the amount charged to buyers. Sellers could receive the full XRP amount due while buyers were charged significantly less than the actual transaction value.

The resulting discrepancy could effectively generate unauthorized XRP that attackers might then transfer through ordinary accounts, trade or deposit into cryptocurrency exchanges. The flaw therefore presented a potential risk to the ledger's intended supply controls, rather than being limited to a conventional payment-processing error.

XRPL Supply Protection Was Also Vulnerable to Integer Overflow

Further investigation found that the ledger's built-in protection mechanisms designed to prevent unauthorized XRP creation could be affected by the same integer overflow problem. This meant the vulnerability potentially extended beyond transaction calculations to the safeguards intended to enforce the network's supply limits.

Developers traced the vulnerable code to payment engine logic introduced in 2015. The flaw had therefore remained undiscovered for approximately eleven years before the researcher reported it in September 2026.

The October 9 disclosure documented the technical risks associated with the issue and the measures taken to correct it. However, the investigation found no evidence that the vulnerability had been used to create unauthorized XRP on a public network.

Emergency XRPL 3.4.1 Update Bypassed the Standard Amendment Process

XRPL developers released xrpld 3.4.1 on September 25 to address the payment engine overflow and the separate Batch inner transaction wrapper validation error. The payment engine correction was implemented as an emergency measure without going through the XRP Ledger's established amendment approval process.

According to the disclosure, this was the first deliberate change to transaction processing made outside that process since the amendment system was introduced more than a decade ago. The decision reflected the seriousness of a vulnerability that could potentially undermine transaction calculations and XRP supply protections.

The fix takes effect when server operators install xrpld 3.4.1, applying the corrected transaction-processing rules. Developers urged operators to upgrade their servers to maintain network synchronization and ensure the security correction is applied.

The disclosure highlights the importance of identifying arithmetic errors in blockchain transaction systems, particularly when the same calculations affect both payment settlement and supply enforcement. Although no exploitation was identified on public XRP Ledger networks, the emergency release addressed a flaw that could have allowed unauthorized XRP creation.


  
Crypto Market Analyst & Onchain Writer

Marcus Renfield covers cryptocurrency markets with a focus on onchain data, Bitcoin price action, and emerging market narratives. His writing examines how capital flows, network activity, and broader market structure influence short- and medium-term trends.

He aims to provide clear, data-informed analysis for readers seeking a deeper understanding of crypto market dynamics.


Check out other news and articles on Google News

Disclaimer:


The articles published on hoka.news are intended to provide up-to-date information on various topics, including cryptocurrency and technology news. The content on our site is not intended as an invitation to buy, sell, or invest in any assets. We encourage readers to conduct their own research and evaluation before making any investment or financial decisions.
hoka.news is not responsible for any losses or damages that may arise from the use of information provided on this site. Investment decisions should be based on thorough research and advice from qualified financial advisors. Information on hoka.news may change without notice, and we do not guarantee the accuracy or completeness of the content published.