XRP Ledger Patches Vulnerability That Threatened Its Fixed Supply
The XRP Ledger has fixed a long-standing software vulnerability that could have allowed an attacker to create large amounts of spendable XRP without providing the required funds. The flaw, disclosed in an official XRP Ledger security report published on Friday, could have undermined the network’s fixed-supply model if successfully exploited.
According to the disclosure, the vulnerability was believed to date back to 2015. Researcher Cayden Liao and Veria AI identified the issue and reported it internally on September 22. Engineers at RippleX, Ripple’s development arm, subsequently reproduced the attack on a standalone server and confirmed that the improperly created XRP could be spent in a later transaction.
RippleX said it found no evidence that the vulnerability had been exploited on any public XRP Ledger network. Developers released the software fix in xrpld 3.4.1 on September 25, initially without publicly explaining the specific issue addressed by the update.
How the Bug Could Have Created XRP Without Payment
The vulnerability involved the XRP Ledger’s built-in decentralized exchange, where accounts can post offers to trade one asset for another. The attack described by researchers relied on a flaw in how the software calculated the total XRP owed when processing multiple offers through a single payment.
An attacker could theoretically have created hundreds of accounts, each offering a small amount of another token in exchange for an unusually large amount of XRP. A single payment could then have been used to execute purchases across those offers simultaneously.
The problem arose when the combined amount of XRP owed became too large for the software to calculate correctly. According to the disclosure, the selling accounts could receive the expected payment while the buying account was charged almost nothing. This mismatch could leave the attacker holding XRP that had not been properly funded by the transaction.
The risk was not simply an incorrect balance displayed in a wallet. RippleX reproduced the attack and confirmed that the newly created XRP could be spent in a subsequent transaction, making the issue a potential supply-integrity vulnerability rather than a cosmetic accounting error.
Why Existing XRP Supply Checks Could Have Failed
The XRP Ledger includes a check after transactions to ensure that no new XRP has appeared unexpectedly. However, the vulnerability could have caused this safeguard to rely on an incorrectly calculated total, allowing the supply check to miss the newly created tokens.
A separate safeguard limits how much XRP an individual account can receive. That protection also would not necessarily have stopped the described attack because the attacker could distribute the resulting XRP across hundreds of accounts instead of concentrating it in a single wallet.
The method reportedly required only a few hundred XRP to establish the accounts involved, with most of that amount recoverable, alongside transaction fees. This made the potential attack particularly concerning: the resources required to attempt it were small compared with the amount of XRP that could theoretically have been created.
The disclosure does not establish that an attacker carried out this process on the live network. Instead, the research demonstrated how the bug could be exploited in a controlled environment, while RippleX reported no evidence of public-network exploitation.
Why the Vulnerability Mattered for XRP’s Fixed Supply
All 100 billion XRP were created when the XRP Ledger launched in 2012. The network’s software is designed so that additional XRP cannot simply be issued through ordinary transactions. That fixed-supply property is an important part of how the asset’s supply is understood by users, exchanges and institutions that rely on the ledger.
A vulnerability capable of creating spendable XRP without proper funding could have weakened that guarantee. If an attacker had generated large quantities of tokens and sold them through exchanges, the resulting activity could have affected market participants and raised questions about the integrity of XRP balances.
The flaw therefore had implications beyond a single account or payment. It potentially threatened a core assumption about the network’s monetary rules: that transaction processing cannot increase the supply of XRP beyond the amount already issued.
The vulnerability was in the software’s handling of exchange offers and transaction accounting, rather than evidence that the XRP Ledger’s fixed-supply design had actually been breached in production. That distinction matters when assessing the incident’s confirmed impact.
Developers Released the Fix in xrpld 3.4.1
RippleX shipped the patch in xrpld 3.4.1, the server software used to operate XRP Ledger nodes, on September 25. The release was made before the public disclosure described the specific vulnerability it repaired.
The September 22 internal report, September 25 software release and Friday disclosure outline the reported timeline from discovery to remediation and public explanation. The sequence also illustrates why coordinated vulnerability disclosure is important: developers can distribute a fix before publishing technical details that might help others reproduce an attack against unpatched systems.
Node operators should consult the official XRP Ledger website and the project’s server software release information for relevant updates and version guidance. The disclosure identifies xrpld 3.4.1 as the version containing the fix.
The available information does not indicate that XRP holders suffered losses from this particular vulnerability. RippleX’s statement that it found no evidence of exploitation on public networks is an important part of the incident’s reported status.
Another Example of Long-Hidden Crypto Security Risks
The XRP Ledger disclosure comes amid a series of cryptocurrency security issues reported in recent months. The source material also points to a Coldcard wallet vulnerability associated with the theft of at least 1,367 BTC and issues that led Core Lightning developers to advise Bitcoin node operators to disconnect affected systems.
These incidents involve different software components and should not be treated as evidence of a single shared vulnerability. They do, however, highlight the importance of testing transaction logic, reviewing safeguards and responding quickly when researchers uncover flaws that could affect digital asset security.
The role of AI in identifying or investigating vulnerabilities has also drawn attention across the industry. In the XRP Ledger case, the reported discovery involved Cayden Liao and Veria AI, but the security significance rests on the demonstrated transaction-accounting flaw and the subsequent patch—not on assumptions about the tools used to find it.
For XRP users, the key takeaway is that developers identified and patched a vulnerability that could have threatened the ledger’s supply rules. The attack was reproduced in a controlled environment, and RippleX reported no evidence of exploitation on public networks. The incident underscores why security reviews and timely software updates remain essential to maintaining trust in blockchain infrastructure.
