The XRP Ledger has patched a critical vulnerability in its payment engine that could have enabled the creation of XRP beyond the network's fixed supply cap. The flaw, present since 2015, was discovered and reported through the XRPL Bug Bounty program on September 22, and publicly disclosed on October 9 with no evidence of exploitation.
The Technical Flaw
The vulnerability existed in the code that settles payments across the XRP Ledger's decentralized exchange. When a single payment consumed multiple offers, the engine added up the amounts using unchecked 64-bit arithmetic. By pushing this sum high enough, it would wrap around—an integer overflow—causing a large number to become small. In this scenario, sellers would be paid in full, but the buyer would be charged only the wrapped, tiny total, effectively creating XRP that never existed.
Compounding the problem, the ledger's safety check designed to prevent XRP creation used the same unchecked math, rendering it unable to detect the very failure it was built to catch.
Attack Cost and Impact
According to the official vulnerability disclosure report, an attack would have required just a few hundred XRP locked up as reserves—which would be returned after removal—plus ordinary transaction fees. An attacker would have needed to place hundreds of deliberately mispriced offers and route a single payment through them. The severity lay in the potential payoff: spendable XRP could have been created in a single validated transaction, fundamentally undermining XRP's core promise of a hard cap at 100 billion tokens.
Discovery and Response Timeline
Cayden Liao and Veria AI discovered and reported the flaw through the bug bounty program on September 22. RippleX reproduced the vulnerability the following day, classified it as critical, and merged the fix immediately. Version 3.4.1 of xrpld shipped on September 25, with more than 80 percent of default Unique Node List validators running it by that date. The patch bypassed the usual amendment vote process and went live as a direct code change across validators as they upgraded.
Public disclosure occurred on October 9, the same day the fixBatchV1_2 amendment went live to address a second, lower-severity bug related to batch transaction wrapping. The XRPL Operations account confirmed no funds were lost from either vulnerability and found no evidence of exploitation on any public network.
