XRP Ledger has fixed a serious security vulnerability that dates back to 2015. This vulnerability theoretically allowed attackers to create approximately 18 trillion XRP through a specially designed transaction; as of September 25th, over 80% of trusted validators had installed the emergency update.

XRPL developers have fixed a serious payment vulnerability that could potentially generate spendable XRP beyond the supply limit.

Researcher Cayden Liao demonstrated that it is possible to construct a transaction to mint approximately 18 trillion XRP.

The security team has not found any evidence that this overflow vulnerability has been exploited on the public internet.

Developers confirmed that as of September 25th, over 80% of the default validators had been upgraded to xrpld 3.4.1.

Another Batch verification fix will take effect on October 9th; prior to this, the verifiers postponed the original launch date.

XRP Ledger Foundation and RippleX confirmed this vulnerability in their disclosure on October 9th, explaining that an error in the online payment engine could have potentially generated more XRP than the established supply cap of 100 billion. Developers reproduced the issue during testing and released version 3.4.1 to fix it. No evidence was found that the vulnerability was exploited on the public internet. Security researchers Cayden Liao and Veria AI received a maximum reward of $250,000 from the vulnerability bounty program for reporting the vulnerability and demonstrating its potential impact.

XRP Ledger Fixes a vulnerability that allows the generation of trillions of XRP

This vulnerability affected the payment engine of XRP Ledger, which is responsible for handling transfers and transactions involving the network's built-in decentralized exchanges.

According to official disclosures, the issue stems from an integer overflow in software written in 2015. An integer overflow refers to a calculation result that exceeds the maximum value that a computer system can represent within the allocated number of bits.

In this case, the payment engine will add up the amounts represented by XRP from multiple quotes in the order book. The software uses a 64-bit integer to calculate the total amount that the buyer should pay when completing a payment involving multiple quotes.

Developers have discovered that attackers can create hundreds of quotes with abnormal pricing, and arrange a payment to consume all these quotes at once. When the calculated total amount exceeds an integer limit, the value will wrap around to a much smaller amount. The system will still record the full XRP amount specified in each seller's quote, while the buyer actually pays only the smaller amount resulting from the overflow. The difference will generate a previously non-existent XRP.

According to XRPL Foundation, the cryptocurrency generated in this way can be transferred to other accounts, used in transactions, or sent to exchanges. The potential outcome described in the report is: "The attacker could have created a much larger amount of spendable XRP than the total supply."

Developers stated that this vulnerability cannot be triggered through ordinary transactions. Attackers need to create hundreds of accounts, post offers with abnormally high prices, and submit a carefully constructed transaction to process these offers together. The existing security checks are ineffective because the method used by the system to verify the supply quantity is the same arithmetic type that caused the original error.

At the same time, another account balance check may also be bypassed, as the newly generated XRP can be distributed across multiple wallets.

Researchers have discovered potential ways to utilize 18 trillion XRP.

This vulnerability came to the attention of developers after security researchers Cayden Liao and Veria AI tested the open-source software XRP Ledger.

Veria Labs announced the research results on October 10th, stating that its automated security testing system detected this issue on September 21st. The following day, the researchers developed a functional proof of concept on their local testing network.

According to the company, the demonstration showed that it is possible to create approximately 18 trillion XRP through a specially designed transaction. According to the researchers' calculations, this number is about 184 times the total target supply of XRP. This figure represents the results of controlled security tests and does not indicate an actual increase in the circulating supply of the cryptocurrency. Liao submitted this vulnerability on September 22 through the official XRPL vulnerability bounty program.

Engineer RippleX reproduced this issue on an independent server and confirmed that the newly generated XRP can be spent in subsequent payments.

The initial report classified this vulnerability as critical, but after confirming the potential consequences, developers upgraded its severity to severe. Veria Labs indicates that if attackers successfully exploit this vulnerability, the entire market value of XRP could be at risk. The company's estimate is based on a market value of approximately $94 billion for XRP at that time.

However, the figure of $94 billion is an estimate by researchers for potential financial exposure and not an confirmed loss. The security team has not found any evidence of unauthorized creation of XRP on the public internet. On October 8th, Veria AI received a reward of up to $250,000 for identifying and responsibly disclosing this issue.

RippleX released an emergency fix without following the regular approval process.

After confirming the vulnerability, engineers from RippleX developed a fix between September 22nd and September 23rd. The patch was incorporated into the xrpld version 3.4.1, which was released on September 25th.

According to official disclosures, developers have added a check mechanism to prevent the payment engine from accepting calculation results that exceed the allowed integer range. The updated software will reject affected calculations and return a standard payment failure, rather than creating additional XRP. Engineers have also strengthened the network's supply verification by replacing the existing arithmetic methods with wider counters to detect similar errors. As a preventive measure, other balance calculations have also been reviewed.

However, the deployment method of this fix has brought about an unusual situation in the governance of XRP Ledger. Typically, changes related to transaction processing must go through the network's amendment system. A certain amendment requires support from over 80% of trusted validators for two consecutive weeks before it can be activated.

In response to this payment overflow vulnerability, developers decided to apply a fix immediately after the validators upgraded their software. XRPL Foundation explained that if the normal process were followed, the vulnerability would be exposed during the approval period and could still be exploited.

Since the XRP Ledger software is open-source, releasing patches may expose the location and nature of vulnerabilities.

Developers ultimately concluded that waiting for the regular amendment process could pose additional security risks. The emergency handling approach also comes with another concern: verifiers running different versions of the software may have differing opinions on how to handle malicious transactions.

In extreme cases, such disagreements may temporarily prevent the network from confirming new ledgers. The foundation stated that this decision was made after consultations with RippleX, validator operators, and other XRPL contributors. As of September 25th, over 80% of the validators in the default Unique Node List had been upgraded to version 3.4.1.

Subsequently, after the immediate security response was completed, the source code was made public. The release record for XRPL Foundation indicates that version 3.4.1 was an emergency update aimed at addressing security-sensitive protocol issues.

XRP Ledger fixes the second security vulnerability before Batch is activated

The disclosure on October 9th also involved another vulnerability in the XRP Ledger Batch transaction function. Batch allows developers to merge up to 8 transactions into a single operation. This function supports different execution modes, including one where all transactions must succeed for the entire operation to be accepted.

During security testing, researchers discovered a validation error related to the way individual transactions are encapsulated within Batch. The protocol requires that each transaction use a specific field named RawTransaction.

However, under certain conditions, the software may accept other field names. Investigators found that different server versions may process these transactions with format errors in different ways.

According to XRPL Foundation, if this feature is activated before the issue is fixed, it may ultimately lead to discrepancies in network verification. The problem was initially discovered during Sherlock Attackathon and was later further investigated by contributor Denis Angell from XRPL Foundation. Engineer Mayukha Vadari from RippleX determined that this vulnerability could pose potential consensus risks between different server versions.

The developer then introduced fixBatchV1_2 amendment. This amendment requires that each Batch transaction use the approved field format and rejects encapsulated transactions with incorrect formats. During the period when the developer was making corrections, the verifiers temporarily withdrew their support for the previous BatchV1_1 activation schedule.

Both fixBatchV1_2 and BatchV1_1 were activated on the XRP Ledger mainnet on October 9th. According to XRPScan data and the verified network reports, the activation on XRP Ledger Batch received support from 30 validators, while 5 validators opposed it.

Previous research on the security review of Batch detailed the emergency release on September 25th and the protective measures required before the activation of that feature. The initial version had previously faced security concerns, including transaction authorization issues identified during developer reviews.

Another security audit conducted by XRP Ledger in August recorded 96 valid vulnerabilities identified in the Sherlock competition, which covered the proposed protocol functions.

Regarding the latest Batch vulnerability, XRPL Foundation has confirmed that at the time the issue was discovered, the affected amendment had not yet been activated on the mainnet. There were no user funds lost, no private keys leaked, and no consensus failures due to this vulnerability. The activation on October 9th means that servers running the old version of the software are now blocked by amendment, and they must be upgraded to version 3.4.1 or higher to remain synchronized.

XRPL Foundation indicates that in future software releases, an additional verification requirement will be added: security issues that have been reported before must be retested in the candidate version before they can be classified as fixed.

According to the foundation, this process will apply to audits, vulnerability bounty programs, AI assisted security testing, and other issues identified during vulnerability assessments.