- The XRP Ledger has fixed a decade-old software vulnerability that could have allowed attackers to create and spend XRP without paying for it, potentially undermining the cryptocurrency’s fixed supply of 100 billion tokens.
RippleX, the engineering team responsible for XRP Ledger development, disclosed the flaw on Oct. 9 in a security report covering vulnerabilities fixed in the xrpld 3.4.1 release. The issue was reported on Sept. 22 through the network’s bug bounty program, and developers confirmed that the exploit worked in a test environment.
The team said it found no evidence that the vulnerability had been exploited on any public network. Developers released the software fix on Sept. 25, before publishing the technical details of the flaw.
How the XRP Ledger Bug Could Have Created New Tokens
The vulnerability involved an arithmetic error in the XRP Ledger’s payment engine, which processes transactions involving assets traded through the network’s built-in exchange. According to the security disclosure, the flaw could occur when a single payment consumed hundreds of offers in an order book. The software added up the XRP owed across those offers using a fixed-width integer calculation without checking whether the total exceeded its maximum value.
When the total became too large, the calculation could wrap around to a much smaller number. The payment engine could then credit sellers with the full XRP amounts specified in their offers while charging the buyer only a fraction of the actual total.
That difference effectively created new XRP. An attacker could have prepared hundreds of accounts, each offering a small amount of another token in exchange for an unusually large quantity of XRP. A single carefully constructed payment could then consume those offers, triggering the calculation error and leaving the attacker with newly created, spendable XRP.
The exploit required only a few hundred XRP to fund the accounts and offers, most of which could be recovered when the accounts or offers were removed, plus ordinary transaction fees.
The vulnerability also bypassed an existing safeguard intended to prevent XRP from being created through transactions. That check relied on similar arithmetic, meaning it could suffer the same overflow and incorrectly conclude that the transaction had not created additional tokens.
A separate balance limit did not necessarily prevent the attack because the newly created XRP could be distributed across hundreds of accounts rather than concentrated in one wallet. The issue appears to have existed since the current payment engine was developed in 2015. Researcher Cayden Liao and Veria AI identified the flaw through the XRP Ledger bug bounty program, and RippleX engineers reproduced it on a standalone server.
The discovery highlights the importance of testing long-established blockchain software, even when it contains safeguards designed to preserve asset balances and transaction integrity.
XRP Ledger Patch Was Released Before Public Disclosure
Developers addressed the vulnerability in xrpld version 3.4.1, released on Sept. 25. The update introduced overflow checks in the payment engine and strengthened the system’s protection against calculations that could produce invalid balances.
The release also included a separate fix for a validation problem involving the network’s Batch transaction feature. That issue was addressed through the fixBatchV1_2 amendment, which activated on the XRP Ledger mainnet on Oct. 9.
The payment-engine vulnerability was handled differently. Rather than waiting for the network’s normal amendment process, the overflow fix took effect as individual servers upgraded to version 3.4.1. The development team said the decision reflected the severity of a flaw that could have enabled unauthorized XRP creation.
Under the network’s standard amendment process, protocol changes generally require support from more than 80% of trusted validators for two consecutive weeks before activation. Developers said delaying the overflow fix through that process would have left a known, potentially critical vulnerability exposed for longer.
The team reported that more than 80% of validators on the default Unique Node List were running version 3.4.1 or later on the day the release became available. The official xrpld 3.4.1 release notes instructed server operators to upgrade to maintain compatibility with the network. Following activation of the Batch amendment, outdated servers risked being unable to remain synchronized with the mainnet.
The disclosure does not indicate that XRP balances were actually inflated or that investors lost funds through this exploit. RippleX explicitly reported no evidence of exploitation on public networks.
For XRP holders, the incident therefore concerns a potential vulnerability rather than a confirmed loss or unauthorized increase in supply. The fixed supply of 100 billion XRP remains the protocol’s intended limit, and the patch was designed to prevent the described attack.
The episode nevertheless illustrates why security remains central to blockchain networks that handle financial transactions. A flaw in transaction accounting can threaten confidence in an asset’s supply rules even when there is no evidence that anyone exploited it.
The development team said it plans to strengthen its security process by retesting reported vulnerabilities against release candidates before marking them as fixed. That approach is intended to reduce the chance that an incomplete correction allows a similar problem to survive into a production release.