Since 2015, a critical flaw in the XRP Ledger payment engine allowed XRP to be created from nothing, circumventing the fixed 100 billion token supply cap. Discovered in late September 2026, patched urgently and disclosed publicly in October, it was never exploited according to RippleX.
🔑 Key Takeaways
- An unverified 64-bit arithmetic flaw in the payment engine triggered an integer overflow
- The internal invariant check used the same faulty calculation and could not detect the error
- Patch v3.4.1 was deployed urgently, bypassing the usual two-week validator vote
- Over 80% of validators adopted the corrected version on deployment day, with no evidence of exploitation
- Public disclosure occurred on October 9, 2026, as Ledger hardware wallet losses hit $93.4M
Origins and Nature of the Vulnerability
The flaw resided in the code of the XRP Ledger payment engine, originally developed in 2015. This system is responsible for executing exchanges on Ripple’s blockchain. The problem stemmed from an arithmetic error: when a payment involved many simultaneous offers, the software summed amounts using unverified 64-bit arithmetic.
By pushing the sum high enough, it “wrapped around,” creating an integer overflow. An enormous number would collapse back into a small number, and sellers received the full XRP amounts owed while the buyer was only debited the minuscule “wrapped” total. The difference represented XRP created artificially, with no backing funds whatsoever.
The ledger did, however, perform a security check called the “invariant,” designed to confirm that no XRP was ever created. But this check relied on the same unverified calculation, rendering it incapable of detecting the very failure it was meant to catch. A safeguard designed to prevent exactly this type of error proved entirely ineffective.
Discovery and Emergency Fix
The vulnerability was reported on September 22, 2026 by researcher Cayden Liao and the company Veria AI through the XRP Ledger bug bounty program, with a severity level of “Major.” The following day, the RippleX team reproduced the bug, upgraded its classification to “Critical,” and integrated a patch. Version 3.4.1 of Xrpld was deployed on September 25, and over 80% of validators on the default unique node list were running it by that same day.
Under normal circumstances, any change to XRP Ledger rules requires approval from more than 80% of validators over two weeks. This time, the fix was applied immediately without waiting for the vote to prevent a publicly exploitable flaw from being revealed before it was patched. The source code was only published after deployment, following a standard procedure designed not to provide a “roadmap” to potential attackers.
| Step | Date | Action | Result |
|---|---|---|---|
| Report | Sep 22, 2026 | Filed by Cayden Liao / Veria AI | Severity “Major” |
| Reproduction | Sep 23, 2026 | RippleX team reproduces bug | Upgraded to “Critical” |
| Deployment | Sep 25, 2026 | Xrpld version 3.4.1 deployed | 80%+ validators updated |
| Disclosure | Oct 9, 2026 | Public security report released | No confirmed exploitation |
“We found no evidence that this vulnerability was exploited on a public network.”
RippleX, XRP Ledger Security Report
Cost and Impact of a Hypothetical Attack
According to the report, the cost of an attack would have been limited: a few hundred XRP locked as collateral, recoverable once the objects were removed, plus standard transaction fees. An attacker would have needed to create several hundred accounts, place specially crafted offers in them to trigger the error, and route a payment through those offers.
It was the potential gain that made the bug catastrophic: RippleX classified it as critical because a single validated transaction could have created XRP exceeding the total supply of 100 billion. This silent token creation would have undermined the asset’s fundamental promise, which rests on a fixed token cap. The 100 billion XRP had been created when the network launched in 2012, and unlike other cryptocurrencies, no new XRP can normally be issued. The artificially generated XRP could have been transferred to exchanges and sold, potentially destabilizing the market.
Second Vulnerability Also Patched
The 3.4.1 update also addressed a second, less severe vulnerability affecting the Batch feature, which allows grouping up to eight transactions into a single operation. The fix was included in the fixBatchV1_2 amendment, deployed to the Mainnet on October 9 alongside BatchV1_1. No fund losses were observed for this second bug either, which had a substantially more limited exploitation potential.
Public Disclosure and Market Context
Public disclosure took place on October 9, 2026, through a detailed report published by the XRP Ledger team. The revelation came during a difficult week for cryptocurrency security, with losses linked to Ledger hardware wallets reaching an estimated $93.4 million, according to Bitcoin.com News.
In addition, Evernorth, a company backed by Ripple, was preparing for its Nasdaq listing under the ticker XRPN the following Monday, with approximately 473 million XRP in its accounts. XRP has also expanded into decentralized finance (DeFi), with Firelight recently activating vault protection on the network.
In a separate legal context, a Malaysian court granted Ripple security over a 60% stake held by Seamless in Tranglo to recover $24 million in unpaid invoices in XRP linked to its ODL (On-Demand Liquidity) service. No element in the sources establishes a direct link between this vulnerability’s revelation and any specific XRP price reaction or documented market movements. Ripple’s communication focused on the responsiveness of the fix and the absence of confirmed exploitation.
Conclusion
The discovery of this decade-old flaw highlights the risks inherent in open-source blockchains: even a seemingly well-designed security check (the invariant) can fail when it relies on the same faulty logic as the system it monitors. The absence of confirmed exploitation and the speed of the patch — three days from report to deployment — reflect the growing maturity of the XRP Ledger security program.
Going forward, the XRPL community must diversify verification methods in the ledger code and accelerate the adoption of updates. For Ripple, the good timing of the fix — ahead of Evernorth’s Nasdaq debut and the public disclosure — may limit any impact on investor confidence. The demonstration that the flaw was never exploited provides reassurance for XRP holders.
Sources
This article is published for informational and educational purposes only. It does not constitute investment advice in any way. Do your own research (DYOR) before making any decisions.
