A decade-old flaw in the XRP Ledger could have allowed an attacker to create and spend new XRP from nothing, breaking the network's fixed supply of 100 billion tokens, according to a security report published Friday. RippleX, Ripple's developer arm, patched the vulnerability in the xrpld 3.4.1 server software release on Sept. 25.

Researcher Cayden Liao and Veria AI found the bug and reported it internally on Sept. 22. RippleX engineers reproduced the attack on a standalone server and confirmed the newly created XRP could be spent in a later transaction. The company said it found no evidence the flaw was ever exploited on any public network.

The vulnerability is believed to date to 2015 — three years after the ledger launched in 2012 with its entire supply of 100 billion XRP pre-created. The ledger's software is designed so no additional XRP can ever enter circulation, a supply cap that institutions using the network treat as a core guarantee.

How did the attack work?

The flaw sat in the ledger's built-in exchange, where accounts post offers to swap one token for another. The attack exploited a counting error in how the software totals payments that sweep up many offers at once.

An attacker would:

• open hundreds of accounts, each posting an offer of a tiny amount of some token in exchange for an unusually large amount of XRP;
• send a single payment that bought every offer simultaneously;
• exploit an integer-style miscount, so the selling accounts received full payouts while the buying account paid almost nothing.

The XRP pocketed this way had not existed before the transaction. According to the researchers, launching the attack required only a few hundred XRP to fund the accounts — most of which could be recovered — plus transaction fees.

Why didn't the ledger's own checks catch it?

Two safeguards should have stopped unauthorized XRP creation. Neither did.

The ledger runs a post-transaction check verifying that no new XRP has appeared, but that check relied on the same miscounted total the attack abused, so it passed. A separate cap limiting how much XRP a single account can receive in one transaction also failed to trigger, because the attack spread payouts across hundreds of accounts.

For institutions, the operational takeaway is stark: a consensus-level invariant — the fixed supply — was unenforceable against a specific class of payment for roughly ten years, and the ledger's own integrity checks were blind to the violation because they shared the faulty arithmetic.

How was it disclosed and fixed?

RippleX shipped the fix in xrpld 3.4.1 on Sept. 25 without disclosing what the release repaired, a common practice that gives operators time to update before details become public. The security report followed on Friday, once deployments had time to propagate.

The disclosure timeline was compressed: internal report on Sept. 22, patch on Sept. 25, public report days later. That schedule mirrors standard coordinated-vulnerability practice for critical consensus bugs.

The incident joins a run of long-hidden crypto flaws surfaced with AI assistance since July, including the Coldcard wallet bug behind the theft of at least 1,367 BTC and vulnerabilities that forced Core Lightning developers to instruct bitcoin node operators to disconnect. Expect AI-assisted auditing to keep pulling pre-production-grade bugs out of legacy crypto codebases, and expect operators still running pre-3.4.1 xrpld versions to face mounting pressure to upgrade.