XRPL patches overflow flaw that could mint spendable XRP

XRPL developers disclosed on Oct. 9 that xrpld 3.4.1 fixed a payment-engine flaw that could create spendable XRP beyond the ledger’s supply. The [XRPL vulnerability disclosure report](https://xrpl.org/blog/2026/vulnerabilitydisclosurereport-bug-20261009) says the bug had likely been present since the current payment engine was written in 2015; RippleX released the fix on Sept. 25, after reproducing the exploit on a standalone server and confirming the XRP could be spent.

How could an order-book payment create XRP?

The flaw was an unchecked 64-bit integer overflow when the payment engine summed amounts owed across multiple order-book offers. In a payment that consumed offers at the best available price, each offer amount could be valid individually while their combined total exceeded the integer’s limit. The sum then wrapped around to a small number.

An attacker could create hundreds of accounts, have each offer a tiny amount of a token for an enormous amount of XRP, then send one payment that consumed all those offers. The engine would credit each offer owner the full XRP amount but charge the buyer only the wrapped total—potentially a few hundred drops plus the fee. The attacker could then spend the XRP held across those accounts.

Two checks failed to stop the transaction. The “no XRP created” invariant added the transaction’s net balance changes with the same kind of 64-bit counter, so that sum also wrapped and appeared consistent with an ordinary fee. The per-account balance check only rejected balances above the total XRP supply; distributing the newly credited XRP across hundreds of accounts kept each balance below that threshold.

What does version 3.4.1 change?

In 3.4.1, the payment engine checks for overflow while adding offer amounts and while combining results from multiple payment paths. If a sum would overflow, that part of the payment fails with a normal “path dry” or “partial payment” result. The report says the transaction then mints nothing. The “no XRP created” invariant also now uses a wider counter that cannot wrap around, and developers hardened several other balance-summing paths as a precaution.

The attack required deliberately constructed offers priced far outside real market liquidity, followed by a payment designed to consume them together. The report says ordinary payments and pathfinding would complete before reaching those offers, and testing found the offers did not block other users’ payments. Veria Labs co-founder Cayden Liao estimated that one exploit transaction could have created about 18 trillion XRP, according to [The Block’s report](https://www.theblock.co/news/ecosystems/2026-10-11-xrp-ledger-patches-decade-old-bug-that-could-have-minted-trillions-of-xrp). That figure is his estimate; XRPL’s disclosure confirms the minting path but does not publish that total.

Why did the fix take effect on upgrade?

XRPL transaction-processing changes normally ship through an amendment: trusted validators must support the change by more than 80% for two weeks before it activates across the network. This fix instead took effect on each server as it upgraded to 3.4.1. The disclosure says more than 80% of validators on the default Unique Node List were running the release on Sept. 25.

That shortened the period when the vulnerability could be exploited after the fix became available. It also created a mixed-version risk: upgraded servers would reject an exploit transaction while older servers might accept it, potentially making them disagree about a ledger. XRPL developers judged that risk preferable to leaving the flaw exposed during an amendment vote and activation period. The report says there was no evidence the bug had been exploited on a public network.