XRP Ledger: A Bug Hidden Since 2015 Could Have Printed XRP Beyond the 100 Billion Cap

On 22 September 2026 a report landed in the XRP Ledger bug bounty inbox with a claim that should have been impossible. With a few hundred carefully priced orders and one payment, the researcher said, anyone could create brand new XRP out of thin air and spend it.

RippleX, the engineering arm of the payments company Ripple, tried it on a test server the same day. It worked. The fake XRP sat in ordinary accounts and could be sent on like any other coin. The flaw had been sitting in the ledger's payment engine since about 2015.

The XRP Ledger Foundation and RippleX published the full story on 9 October 2026, two weeks after a fix had quietly gone out. The researchers credited were Cayden Liao and Veria AI. No XRP was minted, nobody lost money, and there is no evidence anyone ever used the trick. That is the good news. The rest of the story is about how close it came, and the unusual rule the network broke to close it.

A fixed supply, and a hole in it

XRP is the native coin of the XRP Ledger, a public blockchain (a shared record of who owns what, kept in sync by many independent computers) launched in 2012 by David Schwartz, Jed McCaleb and Arthur Britto. Every XRP that will ever exist, 100 billion of them, was created on day one. Ripple holds a large share, much of it in escrow. There is no mining and no way to issue more.

That cap is the whole investment case for a coin like XRP, in the same way a company's share count matters to a shareholder. If a company could secretly print new shares and sell them, every existing share would be worth less, and nobody would trust the share register again. The bug would have let an attacker do exactly that to XRP. In the official disclosure's words, an attacker "could have created spendable XRP far beyond the total supply in a single validated transaction."

At roughly $1.40 per XRP on 10 October, the existing 100 billion are worth about $140 billion on paper. A counterfeit supply on top of that, dumped through exchanges, would have been a disaster for every holder.

The odometer that rolled over

The flaw was an integer overflow. A car's mileage counter is the easiest way to picture it. A counter with six digits can show 999,999 miles. Drive one more mile and it does not show a million; it rolls back to 000,000. Computers store numbers in boxes of a fixed size and some of them behave the same way.

The XRP Ledger counts XRP in "drops", a millionth of an XRP each, using a 64-bit number. That box tops out at roughly 9.2 quintillion drops, about 92 times every XRP in existence. No normal payment comes anywhere close, which is why nobody noticed for a decade.

The attack worked through the ledger's built-in exchange, where users post offers to swap one asset for another, much like limit orders on a stock exchange. The steps, as the disclosure lays them out:

The attacker opens a few hundred accounts. Each account posts an offer to sell a tiny amount of some token for an enormous amount of XRP. Each offer is valid on its own.

From another account, the attacker sends one payment that buys through all of those offers at once.

The payment engine adds up what the buyer owes across every offer. The total is so large it rolls over, like the odometer, to a tiny number. The engine charges the buyer that tiny number, "only a few hundred drops plus the fee", but pays every seller their full price.

The difference is new XRP. All the accounts belong to the attacker, so the attacker now holds XRP that never existed.

The setup cost, the disclosure says, was "a few hundred XRP in account and offer reserves", money that is handed back when the accounts are closed, plus ordinary fees. No insider access was needed.

Two alarms that stayed silent

The ledger had two safety checks meant to catch exactly this, and both failed.

The first is a rule called an invariant, a final check that no transaction creates XRP. It was added about two years after the payment engine was written, and it added up balance changes with the same kind of 64-bit counter. It rolled over in the same way, so the books appeared to balance. The second check only fires if a single account holds more than the entire supply. Spreading the new XRP across hundreds of accounts kept each one under that line.

The rule they broke to fix it

Changes to how the XRP Ledger processes transactions normally go through a process called amendments. The network's trusted validators (the independent servers whose agreement decides which transactions are final, much as member banks must all accept a change to the clearing rules before it takes effect) vote on each change. It switches on only after more than 80 percent of them have supported it for two weeks.

That process would have been fatal here. The server software, called xrpld, is open source, so publishing a fix shows anyone reading it where the hole is. Under the normal process, the hole would have been public and still open for weeks.

So the fix went out on 25 September in xrpld 3.4.1, an "emergency release", built to take effect on each server the moment it upgraded. The source code was held back until the disclosure. The disclosure says this is "the first time a change to transaction processing has deliberately shipped this way since the amendment system was introduced more than ten years ago."

It carried its own risk. For a while, upgraded and older servers followed different rules, and an exploit attempt in that window could have split the network or halted it. That window was short because operators of more than 80 percent of the validators on the default trusted list, a list of about 35, were running 3.4.1 on release day.

The same release fixed a second, unrelated flaw in Batch, a feature that lets one account bundle up to eight transactions as a single unit. It was found by Denis Angell of the XRPL Foundation while re-checking findings from a public Sherlock security contest, and could have stalled the network. Batch was not yet switched on for the main network, so no funds were at risk. Its fix, an amendment called fixBatchV1_2, and Batch itself both went live on 9 October.

Not the first close call this year

This was the third serious XRP Ledger finding of 2026. In February, researcher Pranamya Keshkamat and Cantina AI's automated tool Apex found a flaw in the original Batch feature that would have let an attacker move money out of other people's accounts without their keys. Validators voted it down before it ever went live, and an emergency release, rippled 3.1.1, followed on 23 February.

In March, Ayo Akinyele, a senior director of engineering at Ripple, announced an AI-assisted red team to hunt for bugs in the 14-year-old codebase. The disclosure lists bug bounties, outside audits, public contests, AI testing and formal checks as layers of defence, and says long-dormant bugs like this one are "what the program exists to produce."

Bitcoin has been here too. In August 2010 an overflow in Bitcoin's code let someone create about 184 billion bitcoin in one transaction, and in 2018 a separate bug, CVE-2018-17144, could have let miners break the 21 million limit. The XRP Ledger bug is the same family of mistake, caught before anyone used it.