XRP Ledger Fixes Critical Security Bug That Could Have Created Unlimited XRP

Highlights:

• XRP Ledger fixed a serious security bug that could have allowed hackers to create XRP without permission.
• Developers also fixed another flaw that could have disrupted transactions and network operations on the XRP Ledger.
• The team found no evidence of attacks and urged server operators to update their software.

The XRP Ledger (XRPL) has disclosed two security vulnerabilities, including a critical flaw that could have allowed attackers to create new XRP without authorization. Developers have already fixed both issues through a software update, and investigators found no evidence that attackers exploited the XRP creation bug on any public network.

The XRP Ledger team revealed the findings in an official security report published on October 9, 2026. The report covers an XRP payment engine overflow and a separate transaction validation flaw. Both fixes were included in xrpld version 3.4.1, released on September 25.

⚡️GOOD NEWS: XRP Ledger patches a DECADE-OLD security flaw that could have created BILLIONS of dollars worth of XRP out of thin air.

The bug, dating back to 2015, could have allowed attackers to generate and spend $XRP without funding it, potentially breaking the token's fixed… https://t.co/gwL5nDE6fH pic.twitter.com/06X2rrPRHE

— Coin Bureau (@coinbureau) October 10, 2026

Critical XRP Ledger Bug Could Have Allowed Attackers to Create New Tokens

The more serious vulnerability affected the XRP Ledger’s payment engine, which processes transfers and trades across the network. Researchers discovered that attackers could exploit a calculation error to create spendable XRP without following the network’s supply rules. The issue involved an integer overflow, which occurs when a calculation exceeds the maximum number a system can handle. Instead of rejecting the transaction, the payment engine could calculate an incorrect amount.

An attacker could exploit the flaw by creating hundreds of specially designed trading offers and processing them through a single payment. The system would credit the full amounts to receiving accounts while charging the sending account far less. Even the network’s existing security check failed to detect the error because it used a similar calculation.

According to the report, the vulnerability may have existed since 2015. However, normal transactions could not trigger it, and exploitation required deliberately constructed trading activity. The XRPL bug bounty program received the report on September 22. RippleX engineers reproduced the issue on a standalone server and confirmed that the newly created XRP could be spent. They subsequently classified the vulnerability as critical. Researchers Cayden Liao and Veria AI received credit for identifying and reporting the flaw.

Second XRPL Vulnerability Could Have Disrupted Network Validation

The second vulnerability involved the XRP Ledger’s Batch feature, which allows users to combine up to eight transactions into one operation. Researchers found that the system could accept transactions containing incorrectly formatted internal data. Different server versions could then disagree over whether those transactions were valid.

Such disagreements could have interrupted ledger validation, potentially preventing the network from confirming new transactions. However, the affected Batch amendment had not activated on the main network when developers discovered the problem. The report confirmed that no funds were lost and no consensus failure occurred. Developers addressed the flaw through the fixBatchV1_2 amendment. It activated on October 9, alongside the corrected BatchV1_1 amendment.

XRP Ledger Releases Emergency Fix and Tightens Security Checks

The XRP Ledger team released version 3.4.1 on September 25 to address both vulnerabilities. The payment engine fix took effect immediately after servers upgraded, while the Batch correction required validator approval. Because the XRP creation flaw posed a critical risk, developers implemented its fix without waiting for the usual amendment process.

More than 80% of validators on the default trusted validator list had upgraded on release day. Meanwhile, the team has instructed all server operators to install version 3.4.1 or newer to remain synchronized with the network. Older versions are now blocked by the activated amendment. Developers also plan to strengthen security testing by requiring retesting of previously identified vulnerabilities before fixes receive final approval.