The XRP Ledger has fixed a critical security vulnerability that could have allowed an attacker to create approximately 18 trillion XRP through a specially designed transaction. Developers released an emergency software update on September 25, and more than 80% of trusted validators had upgraded by that date.
The vulnerability dated back to 2015 and affected the network’s payment processing system. According to the XRP Ledger Foundation and RippleX, testing confirmed that the flaw could have created spendable XRP beyond the intended supply of 100 billion tokens.
Developers said they found no evidence that the vulnerability had been exploited on the public network. Security researcher Cayden Liao and Veria AI received the maximum $250,000 bug bounty for discovering and reporting the issue.
Summary
- Developers fixed a critical XRP Ledger vulnerability that could have created trillions of additional XRP.
- Researcher Cayden Liao and Veria AI demonstrated the potential creation of approximately 18 trillion XRP in testing.
- The security team found no evidence that the flaw had been exploited on the public network.
- More than 80% of trusted validators upgraded to xrpld version 3.4.1 on September 25.
- A separate security fix for Batch transactions activated alongside the Batch feature on October 9.
XRP Ledger fixes a bug that could have created trillions of XRP
The vulnerability affected the XRP Ledger’s payment engine, which processes payments involving multiple offers on the network’s decentralized exchange.
The problem originated from an integer overflow in software dating back to 2015. An integer overflow occurs when a calculation produces a number larger than the computer system can represent, causing the result to wrap around to a much smaller value.
In this case, the payment engine used a 64-bit integer to calculate the total amount a buyer owed when completing a payment involving multiple offers.
Researchers found that an attacker could create hundreds of specially priced offers and combine them into a carefully designed transaction. If the calculated total exceeded the integer’s maximum value, the result could become much smaller than the actual amount owed.
The system could then credit sellers with the full XRP amounts specified in their offers even though the buyer paid only the reduced amount calculated by the faulty system. This difference could create new XRP that had not previously existed.
According to the XRP Ledger Foundation, the resulting tokens could potentially be transferred between accounts, traded or sent to cryptocurrency exchanges.
The attack required careful preparation, including creating multiple accounts, placing unusual offers and processing them together in a single transaction. Developers also found that distributing the newly created XRP across multiple wallets could bypass a separate balance check.
Researchers demonstrate a potential 18 trillion XRP exploit
Security researcher Cayden Liao and Veria AI discovered the vulnerability while testing the XRP Ledger’s open-source software.
Veria Labs reported that its automated security testing system identified the issue on September 21. Researchers developed a working proof of concept on a local testing network the following day.
Their demonstration showed that a specially constructed transaction could potentially create approximately 18 trillion XRP, equivalent to roughly 184 times the intended total supply.
This figure represents the potential result of controlled testing, not an actual increase in XRP’s circulating supply.
Liao reported the vulnerability through the official XRPL bug bounty program on September 22. RippleX engineers reproduced the issue on a standalone server and confirmed that the newly created XRP could be spent in a subsequent payment.
Developers initially classified the issue as a major vulnerability but raised its severity to critical after confirming the potential consequences.
Veria Labs warned that a successful exploit could have seriously damaged confidence in XRP and exposed the market to significant financial risk. However, its estimate of potential exposure was not a measure of confirmed losses.
The security team found no evidence of unauthorized XRP creation on public networks. Veria AI received the maximum $250,000 bounty on October 8 after the vulnerability was responsibly disclosed.
Emergency update bypasses the normal approval process
RippleX engineers developed a fix between September 22 and September 23. The correction was included in xrpld version 3.4.1, released on September 25.
The update adds checks to prevent calculations from exceeding the permitted integer range. Instead of allowing an incorrect result to pass through the payment engine, the software rejects the affected calculation and returns a payment failure.
Developers also strengthened supply verification by using a wider counter and reviewed related balance calculations for similar problems.
The response differed from the XRP Ledger’s usual process for introducing protocol changes. Normally, amendments require support from more than 80% of trusted validators for two consecutive weeks before activation.
Developers decided that waiting through the normal approval period would leave the vulnerability exposed for too long. They therefore included the correction in an emergency software release that validators could install immediately.
The approach carried its own risk because servers running different software versions might process a malicious transaction differently. In an extreme case, disagreements could temporarily prevent the network from confirming new ledgers.
The foundation said the emergency response was coordinated with RippleX, validator operators and other XRPL contributors.
By September 25, more than 80% of validators on the default Unique Node List had upgraded to version 3.4.1. The public release subsequently documented the security correction.
A separate Batch transaction vulnerability was also fixed
The October 9 disclosure covered another security issue involving the XRP Ledger’s Batch transaction feature.
Batch allows developers to combine up to eight transactions into a single operation. Depending on the execution mode, the transactions can be processed under conditions that require all of them to succeed or apply other specified rules.
Researchers discovered that the software could accept incorrectly formatted transaction data under certain conditions. The protocol required each transaction inside a Batch to use a field called RawTransaction, but different server versions could handle alternative field names inconsistently.
That difference created a potential consensus risk: validators running different software versions might disagree about how to process the same transaction.
The problem was identified during security testing and further examined by XRPL contributors and RippleX engineers. Developers introduced the fixBatchV1_2 amendment to require the correct field format and reject improperly packaged transactions.
Validators delayed the earlier Batch activation schedule while the issue was addressed. Both fixBatchV1_2 and BatchV1_1 activated on the mainnet on October 9, according to the reported network data.
The Batch feature allows bundled transactions and supports different execution modes, but it must follow consistent validation rules across the network. Developers said the separate vulnerability was fixed before the affected amendments became active on the mainnet.
The foundation reported no user funds lost, no private keys compromised and no consensus failure resulting from this particular Batch flaw.
XRPL strengthens security testing after the disclosures
The two vulnerabilities have drawn attention to the importance of reviewing older code as well as newly introduced features.
The payment overflow bug had existed in software dating back to 2015, while the Batch issue involved a newer transaction feature that required additional validation safeguards.
The XRP Ledger Foundation said it is introducing an extra verification step for future software releases. Previously reported security issues will need to be tested again against release candidates before developers classify them as fixed.
The process is expected to cover findings from traditional security audits, bug bounty submissions, AI-assisted testing and other vulnerability assessments.
For XRP holders, the key distinction is that the reported 18 trillion XRP figure describes what researchers demonstrated in a controlled environment. Developers have said they found no evidence that the vulnerability was exploited on the public network, and the emergency release was designed to prevent the issue from being used in a real transaction.
The disclosures show how a flaw in transaction calculations can threaten a cryptocurrency’s supply rules, even when the underlying network continues operating normally. They also highlight the need to verify security fixes carefully before introducing new protocol features.
