Quick answer: A decade-old XRP Ledger bug let one crafted payment mint spendable XRP beyond the 100 billion cap. RippleX fixed it in xrpld 3.4.1 on Sept. 25, 2026, disclosed it on Oct. 9 and says it found no evidence of exploitation on public networks.
An XRP Ledger bug that sat unnoticed for about a decade could have let an attacker create brand-new XRP and spend it. RippleX says the flaw is fixed and shows no sign of past abuse, but the way it was patched is just as notable as the bug itself.
What happened with the XRP Ledger bug
On Oct. 9, 2026, the XRPL.org developer blog published a vulnerability disclosure report covering two flaws fixed in xrpld 3.4.1. Xrpld is the main server software that runs the network. The serious one was an integer overflow in the payment engine.
Here is how it worked. An attacker opens a few hundred accounts. Each one posts an offer on the ledger’s built-in exchange, selling a tiny amount of some token for a huge amount of XRP. Then a single payment buys every offer at once.
The engine added up what the buyer owed using plain 64-bit math. However, the total was too big to fit, so it wrapped around to a tiny number. As a result, each seller got paid in full, while the buyer paid only a few hundred drops plus the fee. The gap was XRP that should never have existed.
Researcher Cayden Liao and Veria AI reported the flaw on Sept. 22 through the XRPL bug bounty program, rating it Major. RippleX, Ripple’s developer arm, reproduced the mint on a test server. It also confirmed the new XRP could be spent, and raised the severity to critical. CoinDesk reported the same timeline on Oct. 10.
Why two safety checks missed it
The XRP Ledger has a rule that no transaction may create XRP. All 100 billion XRP were issued at launch in 2012, and CoinGecko still lists that as the maximum supply.
Two checks guard that rule. Yet both failed here:
- The “no XRP created” check summed balance changes with the same 64-bit counter. So it wrapped around the same way and saw only a normal fee.
- The per-account limit only trips if one account holds more than the total supply. Spreading the new XRP across hundreds of accounts kept each one under it.
The attack was also cheap. According to the report, it needed a few hundred XRP in account reserves, which come back later, plus fees. On the other hand, it could not happen by accident. No real trader prices offers that badly.
A fix that skipped the vote
The patch is the bigger story for the network. Normally, XRP Ledger rule changes ship as amendments. Each one needs more than 80% of trusted validators to support it for two weeks before it turns on.
This time, the fix took effect on each server as soon as it upgraded. The report calls it the first deliberate change of this kind since the amendment system appeared over ten years ago. The reasoning is simple: open-source code would have exposed the bug for weeks while votes ran.
That bet depended on speed. More than 80% of default validators ran 3.4.1 on Sept. 25, the release day, even though the source code was not public yet. Meanwhile, the second bug, in the new Batch feature, went through the normal route. Its fix amendment went live on Mainnet on Oct. 9, so servers still on old versions are now amendment blocked.
Market data: XRP shrugs
Traders barely reacted. At 07:55 UTC on Oct. 10, XRP traded at $1.40, up 0.1% in 24 hours, per CoinGecko. It is down 5.5% over seven days, and its market value is about $88.7 billion.
That calm makes sense. The XRP Ledger bug was found by a bounty hunter, fixed before disclosure, and never used, as far as anyone can tell. For context on recent demand, see our look at XRP ETF inflows and Paxos support.
Our take: the XRP Ledger bug is a governance test
The XRP Ledger bug is a reminder that “fixed supply” is a software promise, not a law of nature. A single unchecked sum could have broken it. Supply claims on any chain are only as strong as the code and the people checking it.
The response was fast, though. Report to release took three days, and most validators upgraded on day one. Still, skipping the amendment process puts trust in a small group of developers and validators. The report says that path only makes sense when an exploit is “even worse than a network halt.” Holders should watch whether that bar holds.
There is also a pattern. CoinDesk counts a run of long-hidden crypto flaws found with AI help since July, and this one came from a researcher working with Veria AI. Hardware risk is real too, as the recent Ledger CryptoBilis thefts showed.
What to watch next
- Independent audits. The 3.4.1 source code is now public, so outside reviewers can check the fix and the “no exploitation” claim against ledger history.
- Batch adoption. The Batch feature (XLS-56) is now live on Mainnet. Early use will test the new wrapper checks.
- Release process. RippleX says every fixed finding will now be re-tested against each release candidate before it is closed.
XRP Ledger bug FAQ
Was any XRP actually created by the bug?
No evidence of that exists. RippleX says in its Oct. 9, 2026 disclosure that it found no sign the overflow was exploited on any public network.
Do XRP holders need to do anything?
No. The fix lives in the server software that validators and node operators run, not in user wallets. Holders who keep coins in their own wallet can follow our self-custody wallet setup guide for general safety.
Which xrpld version fixes the XRP Ledger bug?
Version 3.4.1, released on Sept. 25, 2026. All server operators must run 3.4.1 or newer to stay in sync, because older servers became amendment blocked on Oct. 9.
Sources
- XRPL.org: Vulnerability Disclosure Report for xrpld 3.4.1
- XRPL.org: Introducing XRP Ledger version 3.4.1
- CoinDesk: XRP Ledger patched decade-old bug that could create billions of dollars in XRP from nothing
- DeFiPrime: XRPL fixes critical XRP payment engine overflow
- CoinGecko: XRP price and supply data
This article is for information only and is not financial advice. Do your own research before you buy or sell any crypto asset.
