The XRP Ledger (XRPL) disclosed two software vulnerabilities on October 9, 2026. The critical bug affected the payment engine's ability to calculate XRP required for trades across multiple offers, while a second flaw impacted the network's Batch transaction feature.
Critical Payment Engine Vulnerability
The payment engine bug could have allowed attackers to create new, spendable XRP through a calculation overflow. When the combined amount of XRP in a transaction exceeded the system's maximum supported value, the payment engine could charge a buyer less XRP than the amount credited to offer owners, effectively creating new XRP out of circulation.
Exploiting the vulnerability required a carefully prepared order book containing hundreds of offers with unusually high prices, followed by a specific payment transaction. The flaw could not be triggered through ordinary payments or trades.
A researcher reported the issue through the XRPL Bug Bounty program on September 22, 2026. The RippleX engineering team reproduced the bug and confirmed that any XRP created through the flaw could be spent. The vulnerability was fixed in xrpld version 3.4.1, released on September 25, with added checks to prevent calculation overflow and strengthened safeguards against unauthorized XRP creation.
XRPL reported no evidence that the vulnerability had been exploited on any public network, and the report does not establish that the flaw caused an actual increase in XRP supply.
Batch Transaction Flaw
The second vulnerability involved XRPL's Batch transaction feature, which allows users to submit multiple transactions together. A flaw in the system allowed a transaction inside a batch to use an incorrectly structured field that servers could still accept and process.
This created a risk that different versions of XRPL software could disagree on whether a transaction was valid, potentially preventing validators from reaching consensus and interrupting ledger validation. The issue did not allow attackers to bypass transaction signatures or directly steal funds.
XRPL addressed the flaw through the fixBatchV1_2 amendment, which requires transactions to use the correct structure. The Batch feature had not been activated on the mainnet when the vulnerability was identified, so no mainnet accounts or funds were affected by this bug.
Network Response and Security Updates
Developers and validator operators withdrew support for the original Batch amendment to reset its activation timeline while the team prepared the security fix. The corrected amendment gained support and activated on the mainnet on October 9, 2026, the same day the vulnerability report was published.
XRPL also outlined a change to its security testing process, planning to retest reported vulnerabilities against release candidates to confirm that fixes work before software releases.
Implications for Users and Operators
Both vulnerabilities have been addressed with no evidence of exploitation or fund loss. The payment engine fix is included in xrpld version 3.4.1, while the Batch issue was addressed through the fixBatchV1_2 amendment. The report does not instruct XRP holders to move their funds or change their private keys. The software upgrade is relevant to XRPL server operators, who need compatible versions to remain synchronized with the network.
