A bug within the XRP Ledger (XRPL) was fixed following a security audit revealing how the system was susceptible to a hack that would have caused about 18.45 trillion XRP to become available for spending.
This issue was located within code dating back to 2015. According to the XRP Ledger Foundation’s October 9 disclosure, developers fixed the issue before any known exploitation on public networks.
The XRPL Vulnerability Exposed a Risk to XRP’s Supply
The vulnerability affected xrpld versions 3.4.0 and earlier, according to the XRP Ledger Foundation. The bug involved integer overflow in the payment engine, which processes payments involving offers in the ledger’s order books.
An integer overflow occurs when a calculation exceeds the numerical range supported by a software data type. In this case, the sum of sufficiently high offers would wrap to a much smaller value rather than produce an error.
Source: Wu Blockchain
The payment engine could thus credit sellers with their entire amount of XRP while debiting the buyer for a sum lower than the actual one. This would create a possible method to generate spendable XRP without the respective payment being made.
XRP has an intended maximum supply of 100 billion tokens. Because the reported exploit could theoretically create approximately 184.5 times that amount, it threatened the integrity of the ledger’s supply rules rather than simply exposing funds held in an individual wallet.
A Carefully Constructed Payment Could Have Created Trillions of XRP
The attack required a specially constructed transaction that combined hundreds of offers. Although each offer could be valid individually, their combined value could exceed the limit of the payment engine’s 64-bit integer calculation.
When the calculation overflowed, the software could process the transaction using an incorrect total. The offer owners would receive their full amounts even though the buyer’s payment did not cover the value transferred.
Existing safeguards also failed to prevent the exploit. The invariant designed to stop unauthorized XRP creation relied on similarly vulnerable arithmetic, while another balance check could be bypassed by distributing the newly created tokens across hundreds of accounts.
According to the disclosure, the theoretical outcome was approximately 18.45 trillion XRP spread across multiple accounts. The tokens could then be spent through subsequent transactions, making the flaw more serious than a calculation error that affected only displayed balances.
However, the reported figure represents the potential result of a successful exploit, not evidence that these tokens were created on the public network. The Foundation reported no known public-network exploitation of the vulnerability.
XRPL Developers Released the Fix in Version 3.4.1
The fix for the issue was created and reviewed by RippleX between September 22 and 23 prior to the release of xrpld version 3.4.1 on September 25. According to the Foundation, over 80% of validators on the default Unique Node List were using the patched version of the code on launch day.
The update introduced explicit overflow checks when calculating offer totals and combining results from multiple payment paths. Transactions that exceed the supported numerical range can now fail instead of allowing the payment engine to process an incorrect amount.
Developers also expanded the counter used by the no-XRP-creation invariant and strengthened other balance calculations. These modifications helped improve the arithmetic and strengthened the measures put in place to avoid creating tokens without permission.
The response bypassed the usual amendment activation process for changes to transaction processing. Usually, amending the XRPL calls for continuous backing from over 80% of trusted validators for a period of two weeks.
With the emergency method, the change went into effect once a validator operator installed it on his or her server. The Foundation said the decision reduced the time the network remained exposed, although differences between upgraded and unpatched servers could temporarily create transaction-processing inconsistencies.
Cayden Liao’s Team Reported the Flaw and Received a Bounty
Cayden Liao and his team at Veria AI discovered the issue while examining the open-source rippled codebase with an AI-assisted security agent. According to Veria AI’s technical account, the researchers developed a proof of concept on a local network before reporting the vulnerability through XRPL’s bug bounty program on September 22.
RippleX independently reproduced the exploit and confirmed its severity. Veria AI subsequently reported receiving a $250,000 bug bounty, the program’s maximum award for the finding.
The discovery also revealed how a long-standing defect can survive when separate software safeguards share the same underlying weakness. The vulnerable calculation dated to 2015, while a later safety check used arithmetic that could fail under similar conditions.
FAQs
How much XRP could the vulnerability have created?
The reported exploit could theoretically have created approximately 18.45 trillion spendable XRP, about 184.5 times the intended 100 billion supply.
How did the bug lead to the creation of XRP?
A transaction with special characteristics could create hundreds of orders, resulting in a calculation overflow and hence crediting of sellers without receiving the proper payment from the payment engine.
Why was the bug significant?
XRP had a total supply cap of 100 billion tokens. This bug could result in creating 184.5 times the number of XRP tokens.
