The XRP Ledger Bug That Could Have Minted Billions of Fake XRP, Explained

On October 9, 2026, RippleX — the engineering group that maintains the XRP Ledger’s core software — disclosed that it had just patched a critical bug in the network’s payment engine that could have let someone mint spendable XRP beyond the ledger’s fixed 100 billion supply cap. The flaw, a 64-bit integer overflow, had reportedly been sitting in the code since the payment engine was written in 2015. RippleX says it found no evidence anyone ever used it, and the fix was already live for three days before the public write-up went out.

Here’s what the bug actually did, how it was caught, why the patch broke with the XRP Ledger’s usual playbook for shipping changes, and what any of this means if you hold XRP.

What the Bug Actually Was

The XRP Ledger has a built-in decentralized exchange, where accounts can place buy and sell offers for different assets. A single payment can automatically “cross” — settle against — several of those offers at once if that’s what’s needed to get the best available price for the sender.

The bug lived in the arithmetic the payment engine used when a payment crossed a large number of offers in one go. According to RippleX’s disclosure and corroborating technical coverage, the code added up what the paying account owed across all those offers using plain 64-bit integer addition, with no check for whether the running total had overflowed the maximum size a 64-bit number can hold (XRPL Vulnerability Disclosure Report, Oct. 9, 2026). Line up enough offers asking for a large enough amount of XRP in a single payment, and that sum could wrap around past the 64-bit ceiling — which, in practice, meant the ledger could end up crediting far more spendable XRP to an account than the payment should have produced.

RippleX says it reproduced the flaw on a standalone test server and in its own unit tests, and confirmed that the improperly minted XRP could then be spent in a normal follow-up transaction (CoinDesk; BeInCrypto). That confirmation is what pushed the bug’s internal severity rating from “Major” to “Critical” — it wasn’t a theoretical accounting glitch, it was a path to real, usable XRP that shouldn’t exist.

Exploiting it wasn’t trivial, though. An attacker would have needed to deliberately construct a large set of mispriced offers and route a single payment through all of them at once — not something an ordinary payment comes anywhere close to doing by accident, which is likely a big part of why a bug present since 2015 appears to have gone unused for about a decade.

The Timeline, From Discovery to Patch

The disclosure report and subsequent coverage lay out a fast turnaround once the bug was actually found:

• September 22, 2026: Security researcher Cayden Liao, working with the AI auditing tool Veria AI, reported the overflow through the XRPL bug bounty program. The initial report rated it “Major.”
• Shortly after: RippleX engineers reproduced the issue, confirmed the minted XRP was spendable, and raised the severity to “Critical.”
• September 25, 2026: A fix shipped in the xrpld 3.4.1 release — three days after the initial report.
• October 9, 2026: RippleX published the full vulnerability disclosure report publicly, two weeks after the patch was already live (xrpl.org).

The same xrpld 3.4.1 release also quietly fixed a second, unrelated bug: a validation flaw in how the ledger’s Batch feature wraps “inner” transactions. That second fix needed its own validator-approved amendment, called fixBatchV1_2, which activated on the mainnet on October 9 — the same day as the public disclosure. RippleX said no funds were lost and no mainnet transactions were processed incorrectly because of that second bug, since the Batch functionality it affects hadn’t been broadly enabled yet. (This is a different Batch-related bug from the one that paused the original Batch amendment back in February 2026 — that earlier flaw was in signature validation, caught before Batch ever reached mainnet.)

Why the Patch Skipped the Normal Validator Vote

This is the part of the story that’s arguably more unusual than the bug itself. The XRP Ledger normally changes its rules through an “amendment” process: a proposed change needs support from more than 80% of trusted validators, sustained for 14 consecutive days, before it activates. That process is deliberately slow and deliberately public — anyone can watch a change working its way toward activation, and see exactly what code is being voted on.

For this bug, RippleX, the XRP Ledger Foundation, and operators representing over 80% of the network’s validators instead coordinated to install the xrpld 3.4.1 patch immediately, without running it through that public vote, and without publishing the underlying code changes at the time. More than 80% of default validators reportedly upgraded on release day, before the specifics of what they were patching were made public (KuCoin News; coingape).

The reasoning, as RippleX framed it: publishing a fix through the normal open amendment process would have meant publishing the exact flaw, in code, while it was still live and exploitable on every unpatched node. Fixing it first and explaining it later was judged to be the safer order of operations — but it’s also, per multiple reports, the first time a change to the XRP Ledger’s transaction-processing logic has shipped this way since the amendment system itself was introduced over a decade ago. Some in the community pushed back on the closed-door rollout; RippleX has said the full technical retrospective and code will be published once disclosure no longer carries a security risk.

Core Bug vs. Protocol Amendment: Why This One Was Different

It’s worth separating what happened here from the more familiar story of an XRP Ledger upgrade getting delayed or caught in validator voting, which is usually how changes to the ledger make headlines.

	A protocol amendment (e.g. Batch, Permission Delegation)	A core server patch (this bug)
What it changes	Adds or modifies ledger rules/features	Fixes a flaw in existing server software
Normal rollout	80%+ validator vote, sustained 14 days	Ships whenever a new software version is released
Can it be rushed?	No — the vote threshold and duration are protocol rules	Yes, if validators choose to upgrade immediately
Public visibility before activation	Full — code and vote progress are public	Can be withheld if disclosure itself is a security risk
What happened here	N/A for this bug	Patched Sept. 25; disclosed Oct. 9, bypassing the amendment process by coordinated validator agreement

That distinction matters because it shows the difference between a planned upgrade and an emergency fix. XRP Ledger upgrades like Batch and Permission Delegation go through the slow, public amendment process because they’re new features that need broad agreement before they’re safe to turn on. A bug that’s actively exploitable gets handled differently, because the normal transparency of that process would itself become the risk.

What This Means If You Hold XRP

Nothing about this requires XRP holders to do anything. The bug was in the server software that runs the network, not in individual wallets, private keys, or exchange balances, and RippleX says it found no evidence the flaw was ever used to actually create unauthorized XRP on the public network. The 100 billion supply cap — one of XRP’s defining features relative to inflationary tokens — held, as far as anyone has been able to verify.

The more useful takeaway is less about this specific bug and more about what it says about any blockchain’s core code: the XRP Ledger’s payment-settlement logic had gone unaudited enough to carry a critical, decade-old overflow bug, discovered only because an AI-assisted auditing tool and a researcher went looking for it in 2026. That’s consistent with a broader pattern this year — AI-assisted auditing has now surfaced several XRPL-related flaws before they caused damage, including the Batch signature bug from earlier in 2026. It’s a reasonable argument for why formal, AI-augmented code review is becoming a standard part of how major blockchains stay safe, not an optional extra.

As always, this isn’t financial advice — a patched bug with no confirmed exploitation isn’t a reason to make any trading decision either way, and anyone with specific exposure through an exchange or custodian should check that platform’s own statement rather than rely on secondhand summaries like this one.