XRP Ledger Reveals Critical Bug That Could Have Minted XRP Beyond Its 100 Billion Supply

The XRP Ledger (XRPL) has disclosed a vital vulnerability in its cost engine that might have allowed an attacker to create new XRP past the community’s mounted provide of 100 billion tokens and spend it like every other XRP. The flaw sat undetected within the code for a couple of decade and was mounted earlier than any recognized exploitation, based on the community’s builders.

The small print had been revealed in an official Vulnerability Disclosure Report on October 9, 2026. The report covers two bugs mounted in xrpld 3.4.1, which XRPL builders described at launch as an emergency launch to repair security-sensitive points. xrpld, previously generally known as rippled, is the reference server software program that validators and node operators run to course of transactions on the XRP Ledger. When Crypto Instances coated the xrpld 3.4.1 update for node operators on September 25, the cost engine flaw had not but been made public.

How the XRP Overflow Bug Labored

The XRP Ledger has a built-in decentralized trade (DEX) the place customers place provides to commerce XRP and different tokens. When a single cost consumes many provides from this order ebook, the cost engine provides up the XRP owed throughout all of them. In accordance with the disclosure report, that sum used plain 64-bit integer addition with no overflow verify.

XRP balances are saved as integers with a set most worth. When a sum exceeded that most, it didn’t fail with an error. As a substitute, it wrapped round to a really small quantity. The engine then credited each provide proprietor with their full requested quantity whereas charging the customer solely the wrapped-around complete. The distinction was new XRP that ought to by no means have existed.

Two current security checks didn’t catch the issue. The ledger’s “no XRP created” invariant, a built-in rule that confirms no transaction creates XRP, used the identical sort of 64-bit counter, so it wrapped round in the identical approach and noticed solely a standard transaction payment. A separate per-account verify fails solely when a single account holds greater than the overall XRP provide, and the assault prevented this by spreading the minted XRP throughout a whole lot of accounts.

The report states that the bug had seemingly been current for the reason that present cost engine was written in 2015, and that the invariant verify added two years later was constructed on the identical unchecked arithmetic.

What an Assault Would Have Required

An attacker would have created a couple of hundred accounts, positioned a suggestion from every one promoting a tiny quantity of a token for a really great amount of XRP, after which despatched one cost that purchased by means of all of these provides without delay. The customer would have been charged just a few hundred drops, the smallest unit of XRP, plus the transaction payment.

In accordance with the impression evaluation, the true price was a couple of hundred XRP in account and provide reserves, that are returned when these objects are eliminated, plus atypical charges. The minted XRP may then have been moved, traded, or despatched to exchanges.

The report notes the assault couldn’t be triggered by chance. It required a whole lot of provides priced in a approach no actual dealer would use, and no regular cost comes near the values wanted to trigger an overflow. A secondary declare within the unique report, that such provides could possibly be used to block different customers’ funds, was examined and located to not be a sensible assault.

“Now we have discovered no proof that this challenge was exploited on any public community,” the XRPL disclosure mentioned.

Discovery and Incident Timeline

The vulnerability was submitted by means of the XRPL Bug Bounty program on September 22, 2026, by researcher Cayden Liao and Veria AI, who additionally offered a proof of idea. The submission rated the discovering as Main.

The incident response timeline exhibits that the RippleX engineering group, the developer arm of Ripple, reproduced the assault the identical day on a neighborhood standalone server and in unit assessments, confirmed the minted XRP could possibly be spent, and raised the severity to vital. The repair was developed privately on September 22 and 23, merged into the primary 3.4.1 launch candidate on September 23, and launched on September 25. On launch day, greater than 80% of validators on the default Distinctive Node Listing (UNL), the listing of trusted validators most servers observe, had been operating 3.4.1 or later.

Why the Repair Skipped the Modification Course of

Modifications to how the XRP Ledger processes transactions usually undergo the modification course of. A brand new rule ships within the software program switched off and prompts solely after it retains assist from greater than 80% of trusted validators for 2 weeks.

This repair took impact on every server as quickly because it upgraded. The report says that is the primary time a change to transaction processing has intentionally shipped this manner for the reason that modification system was launched greater than ten years in the past. As a result of xrpld is open supply, publishing the repair by means of the conventional course of would have uncovered the bug for weeks whereas it remained exploitable on Mainnet.

The builders acknowledged the trade-off. In the course of the improve window, an exploit try may have prompted upgraded and older servers to disagree on the ledger, and within the worst case halt the community. The report judged a halt preferable to an incorrect ledger state that will be arduous to roll again. The choice was made collectively by the XRPL Basis, RippleX and XRPL validators, and the report stresses that it doesn’t change how protocol adjustments are usually made. The supply code for xrpld 3.4.1 was withheld at launch and has now been published on GitHub.

Second Repair: Batch Transaction Wrapper Validation

The identical launch addressed a lower-severity flaw within the Batch function, outlined within the XLS-56 standard (XRP Ledger Normal 56). Batch lets one account submit as much as eight transactions as a single unit. The specification requires every interior transaction to be wrapped in a discipline referred to as RawTransaction, however the server didn’t implement this.

The problem was first logged as discovering F48 within the Sherlock Attackathon, a public safety audit contest, and rated low severity. On September 18, 2026, Denis Angell of the XRPL Basis confirmed that the sooner repair was incomplete. On September 22, Mayukha Vadari of RippleX discovered that the hole may trigger servers operating variations 3.3.0 and three.4.0 to disagree on whether or not a transaction was legitimate, doubtlessly stopping ledger validation.

On the time, the BatchV1_1 modification held majority assist and was scheduled to activate on September 29. Ripple and different validator operators switched their votes to “no” to reset its activation clock till a repair was prepared. The fixBatchV1_2 modification, shipped in 3.4.1, now rejects any Batch transaction that makes use of a special wrapper. Each fixBatchV1_2 and BatchV1_1 activated on Mainnet on October 9, 2026. No Batch modification was lively on Mainnet when the flaw was discovered, so no accounts or funds had been affected. The unique Batch modification had been withdrawn earlier this yr after a separate vulnerability was reported in February.

Why It Issues for XRP Holders

In accordance with XRPL documentation, 100 billion XRP existed when the ledger was created, and the protocol’s guidelines don’t permit new XRP to be issued. The overflow bug may have damaged that core assure, although the sensible threat on public networks was low given the deliberate setup the assault required.

The report locations the discovering inside a layered safety method that RippleX outlined in June, combining unbiased audits, public attackathons, AI-assisted crimson teaming, fuzz testing and formal verification alongside the bug bounty. As an extra step, each safety discovering marked as mounted will now be retested towards every launch candidate earlier than it’s closed.

What Node Operators Must Do

All XRPL server operators should run xrpld 3.4.1 or newer to remain in sync with the community. With fixBatchV1_2 now lively, older servers are amendment-blocked, meaning they can no longer process new ledgers until they upgrade. Security issues can be reported through the xrpld Security Policy.

Additionally Learn: Ledger Confirms Hardware Implant Amid $86M Loss Probe, Urges Users to Re-Seed 

Disclaimer: The data researched and reported by The Crypto Instances is for informational functions solely and isn’t an alternative choice to skilled monetary recommendation. Investing in crypto belongings includes vital threat because of market volatility. At all times Do Your Personal Analysis (DYOR) and seek the advice of with a certified Monetary Advisor earlier than making any funding choices.