XRP Ledger bug could have created billions of XRP from nothing before a quiet patch

A newly disclosed XRP Ledger bug could have let an attacker create XRP out of nothing, quietly breaking the one promise every XRP holder relies on: that the supply is capped at 100 billion tokens. The flaw sat in the ledger's payment code for roughly a decade. It was reported on Sept. 22, fixed in a server update three days later, and only explained to the public on Oct. 9, once most of the network had already upgraded. RippleX, Ripple's developer arm, says it found no sign that anyone ever used it.

That last point is the good news. The rest of the story is a useful look at how blockchain security actually works behind the scenes, and why "the code is the law" only holds as long as the code is right.

What happened

According to CoinDesk and Bitcoin.com News, security researcher Cayden Liao and the firm Veria AI reported the issue through the XRPL Bug Bounty program on Sept. 22, 2026. They rated it "Major." RippleX reproduced the attack on a standalone server the next day, upgraded the rating to critical and merged a fix.

The fix shipped on Sept. 25 as part of xrpld 3.4.1, the server software that validators and node operators run. The release notes did not say what was being repaired. That silence was deliberate. Publishing the details before servers upgraded would have handed attackers a recipe.

Bitcoin.com News reports that more than 80% of validators on the default Unique Node List were running 3.4.1 on the day it came out. The XRPL Operations account has since made 3.4.1 the minimum required version. The public vulnerability report followed on Oct. 9.

"We have found no evidence that this issue was exploited on any public network," the XRPL Operations account said, as quoted by Bitcoin.com News.

How the XRP Ledger bug worked

The XRP Ledger has a decentralized exchange built directly into the protocol. Accounts can post offers to trade one token for another, and a single payment can travel through many of those offers at once to find the best path.

The problem was in how the payment engine added up the XRP owed across all those offers. Per Bitcoin.com News, the code used unchecked 64 bit arithmetic. If the total grew large enough, the number would overflow and wrap around to a small value, the same way an old car odometer rolls back to zero.

The attack in plain terms

CoinDesk describes the theoretical attack like this:

1. An attacker opens hundreds of accounts.
2. Each account posts a tiny offer to sell some token for an absurdly large amount of XRP.
3. The attacker sends one payment that fills all of those offers at the same time.
4. The combined XRP total overflows. Every selling account gets paid in full, but the buyer is charged only the small wrapped number.

The gap between what was paid out and what was charged is XRP that never existed before. CoinGape reports the flaw could have silently minted billions of XRP.

The cost to try it was low. CoinDesk says an attacker would have needed only a few hundred XRP to open the accounts, most of which could be recovered, plus normal transaction fees.

Why the safety checks missed it

The XRP Ledger runs a check after every transaction, known as an invariant, that is supposed to confirm no new XRP has appeared. That should have caught this. It did not, because the check relied on the same miscounted total. In other words, the guard was doing math with the same broken calculator.

A separate limit on how much XRP a single account can receive would not have helped either. The fake XRP was spread across hundreds of accounts, so no single one stood out.

Why it matters

XRP's value story rests heavily on scarcity. All 100 billion tokens were created when the ledger launched in 2012, and the software is not supposed to allow more. A working exploit that printed XRP would have undermined that claim in a way no price chart could fix.

It also would have been hard to spot quickly. Because the minting happened inside an otherwise normal looking payment, and because the built in check was blind to it, the extra supply could have moved through the network before anyone noticed.

If you are newer to how ledgers track balances, our explainer on what a blockchain is covers why rules like a fixed supply are enforced by software rather than by any company.

Part of a bigger pattern

CoinDesk notes this is one of several long hidden crypto security flaws found with help from AI tools since July. It points to the Coldcard wallet bug, which it links to the theft of at least 1,367 BTC, and to vulnerabilities that led Core Lightning to tell bitcoin node operators to disconnect.

That trend cuts both ways. The same tools that help researchers find old bugs can help attackers find them too. We covered a related argument in our piece on an Ethereum researcher's call for crypto "bunker mode" as AI gets better at probing security.

A second, smaller fix

The same release addressed a lower severity issue in how Batch transactions are wrapped. Bitcoin.com News reports that fix sits behind an amendment called fixBatchV1_2, which went live on mainnet on Oct. 9 along with BatchV1_1. The report says no funds were lost from that bug.

The main overflow fix took a different route. It was shipped as a direct code change rather than through the ledger's usual amendment vote, so it took effect as each server upgraded. That is unusual for the XRP Ledger, and it reflects how serious the developers judged the risk.

Who is affected

For most people holding XRP, the answer is: nobody needs to do anything.

• Everyday holders: If you hold XRP on an exchange or in a wallet app, your balance was not touched. RippleX found no evidence the bug was used, and the fix is already live across the network.
• Node operators and validators: You must run xrpld 3.4.1 or later. It is now the minimum required version.
• Developers and businesses on the XRPL: It is worth reviewing any internal tools that rely on the ledger's own supply checks, since this case shows those checks can share the same blind spots as the code they watch.

What you should do

You do not need to move your coins. But this is a good moment to check your general habits, because news about crypto bugs tends to attract scammers.

• Ignore any message claiming you must "migrate," "verify" or "upgrade" your XRP wallet because of this bug. That is a classic phishing setup. Our guide on how to spot a crypto scam walks through the warning signs.
• Never share a seed phrase or private key with anyone, for any reason. Here is a refresher on how crypto wallets work and which kind protects you best.
• Keep wallet apps and hardware wallet firmware updated from official sources only. The recent Ledger CryptoBilis hack is a reminder of how much damage a compromised tool can do.

What to watch next

The bigger question is how many similar bugs are still out there. Payment engines on older blockchains were written years ago, often before modern testing tools existed, and AI assisted code review is now surfacing problems at a steady pace.

For the XRP Ledger specifically, watch for a deeper technical write up of the fix and any changes to how the invariant checks are designed. A check that uses its own independent math, rather than reusing the payment engine's numbers, would be a natural next step.

For more coverage of crypto security and regulation, visit our crypto news page.

Frequently asked questions

Was any XRP actually created by this bug?

RippleX says it found no evidence the flaw was exploited on any public network. The fix shipped on Sept. 25 before details were made public.

Do I need to do anything with my XRP?

No. Holders do not need to move funds or update anything. Only people running XRP Ledger servers need to be on xrpld 3.4.1 or later.

Who found the XRP Ledger bug?

Researcher Cayden Liao and Veria AI reported it through the XRPL Bug Bounty program on Sept. 22, 2026, according to CoinDesk.

Why was the fix kept quiet at first?

Explaining the bug before servers upgraded would have shown attackers how to use it. Developers shipped the patch first and disclosed the details on Oct. 9.