The XRP Ledger blockchain team published a report on the two vulnerabilities, both of which were addressed in xrpld 3.4.1. The team also strengthened balance checks and plans to verify each patched vulnerability again in new release candidates before closing the related reports.

Overflow could have created unbacked XRP

The first vulnerability was discovered on September 22, 2026, through the XRPL bug bounty program. An integer overflow in the payment engine could have allowed an attacker to create XRP without proper backing by using specially crafted offers in the order book and a single payment.

When processing hundreds of offers, the software could incorrectly add XRP amounts. Instead of returning an error, an excessively large total could wrap into a small number. Offer owners would still receive the full amounts, while the buyer would pay a much smaller amount.

A standard check intended to prevent a transaction from creating new XRP could also fail because of a similar overflow. The XRPL team estimated that the vulnerability may have existed since 2015, when the current payment engine was introduced.

Version 3.4.1 added overflow checks when calculating totals and rejects invalid operations. The team said there was no evidence that the vulnerability had been exploited on public networks.

Batch transaction flaw threatened network consistency

The second vulnerability emerged during a further review of results from the Sherlock Attackathon. Denis Angell of the XRPL Foundation confirmed on September 18 that an earlier fix was incomplete. Mayukha Vadari of RippleX later determined that the flaw could cause different versions of the server software to reach conflicting conclusions.

The issue involved the Batch mechanism, which can bundle as many as eight transactions into one batch. The server did not check whether each inner transaction was enclosed in the required RawTransaction field. Different versions of xrpld could therefore interpret the validity of the same operation differently, potentially halting validation of new ledgers under certain conditions.

The team fixed the flaw through the fixBatchV1_2 update, which was activated on the mainnet on October 9. Before that activation, the issue could not be exploited to affect the mainnet because the corresponding BatchV1_1 function remained inactive.

Other XRPL security work

Ripple Labs also worked during 2026 to strengthen security and expand XRPL’s capabilities. In March, RippleX researchers presented an approach to confidential transfers for multi-purpose tokens designed to protect user data.

In April, the company announced a multi-phase plan to prepare XRPL for quantum-computing threats, including a transition to post-quantum cryptography by 2028. In October, Brazil’s CSD BR began the first stage of a partnership with Ripple Labs to tokenize shares of BTG Pactual investment funds on XRPL.

Source: Incrypted