XRP Ledger Discloses Overflow Bug That Could Have Minted XRP Beyond Its 100 Billion Cap
Key Takeaways
- •A critical 64-bit integer overflow in xrpld versions 3.4.0 and earlier could have allowed attackers to mint XRP beyond the network's 100 billion token hard cap, potentially exceeding the entire total supply in a single transaction.
- •The exploit would have cost only a few hundred XRP in largely recoverable reserves and fees, using specially crafted offers from hundreds of accounts whose inflated balances evaded the ledger's existing safety checks.
- •Researcher Cayden Liao reported the flaw through the XRPL Bug Bounty program on September 22, 2026, and RippleX released the emergency xrpld 3.4.1 patch on September 25 without going through the standard validator voting amendment process.
- •Investigators found no evidence the bug was ever exploited on a public network, reporting no loss of funds, no compromised keys, and no consensus problems, with the token supply appearing intact.
- •The vulnerability is believed to have existed since the payment engine was built around 2015, and node operators still running xrpld 3.4.0 or earlier remain exposed to a now publicly documented supply-breaking flaw.

The XRP Ledger's developers have disclosed a critical overflow bug that could have allowed an attacker to create XRP out of thin air, exceeding the network's hard cap of 100 billion tokens. The flaw affected xrpld, the ledger's core server software, in versions 3.4.0 and earlier. It was quietly patched in September and made public on October 9, 2026. Investigators found no evidence it was ever exploited on a public network.
How the bug worked
The vulnerability sat in how xrpld tallied payment amounts. When a single payment drew liquidity from multiple offers on the decentralized order book, the software used a 64-bit integer to keep a running total of the XRP involved. If that total grew past the largest number the integer could hold, it wrapped around to a value far smaller than reality. Overflow errors like this are a classic category of software flaw—arithmetic that outgrows the fixed size of the variable storing the result—and they are among the first hazards reviewers look for in code that moves money.
An attacker could exploit that gap to spend XRP that did not exist. Because the inflated balances were scattered across many accounts, the ledger's existing safety checks failed to flag the discrepancy—allowing the books to appear balanced while the actual supply quietly ballooned.
The cost of pulling off such an attack was strikingly low. According to the disclosure, the exploit required specially crafted offers from hundreds of accounts, costing only a few hundred XRP in reserves and fees, most of which would have been recoverable. The amount of XRP that could have been minted in a single transaction may have exceeded the token's entire total supply.
A quiet fix, then a public disclosure
The vulnerability was reported on September 22, 2026, by researcher Cayden Liao through the XRPL Bug Bounty program. RippleX, Ripple's developer arm, confirmed the issue and reproduced the attack on a standalone server, verifying that the excess XRP could be spent in follow-up transactions.
Three days after the report, on September 25, 2026, an emergency release went out: xrpld 3.4.1. The fix also skipped the ledger's usual amendment process, under which changes to the network's rules normally take effect only after a validator voting procedure. This patch was deployed immediately instead.
The public disclosure followed on October 9, roughly two weeks after the patched software shipped. The team reported no loss of funds, no compromised keys, and no consensus problems tied to the bug. That sequencing follows coordinated vulnerability disclosure, the standard practice in software security of shipping fixes before publishing details, giving operators a window to upgrade before information that could guide an attack becomes public. The XRPL Bug Bounty program that produced the report is part of the same apparatus—one that pays independent researchers to surface flaws privately rather than exploit or disclose them on their own.
A decade in hiding
The flaw is thought to have existed since the payment engine was first built, around 2015—meaning the code processed payments for years with a latent overflow sitting inside it. Bugs capable of inflating a chain's native asset are rare, but not unprecedented: in 2018, Bitcoin Core developers shipped an emergency patch for a flaw that could likewise have allowed an attacker to create bitcoin outside the network's issuance rules.
What this means for XRP holders and the ledger
For XRP holders, the immediate takeaway is reassuring: there is no evidence the bug was ever exploited, and the integrity of the token supply appears intact. The episode is also a reminder that a hard supply cap is ultimately enforced by code—and is only as reliable as that code.
The decision to bypass the amendment process, however, deserves attention. A known path to unlimited XRP creation is not something that can wait on a governance vote, but emergency patches that skip normal procedures place significant trust in the core development team. In this case, the network's security depended on validators and node operators upgrading quickly.
Node operators still running xrpld 3.4.0 or earlier are the most direct audience for this news. The patched version, 3.4.1, has been available since September 25, and anyone who has not upgraded is running software with a now publicly documented, supply-breaking flaw.
Source: CryptoBriefing