A bug bounty submission from researcher Cayden Liao and Veria AI exposed an XRP Ledger payment engine flaw that could have minted spendable XRP beyond the token’s 100 billion cap. The disclosure report published on 9 October is one of the most candid accounts of bounty triage and emergency patching we have seen this year.
What happened
On 9 October 2026 the XRP Ledger developers published a vulnerability disclosure report covering two bugs fixed in xrpld 3.4.1, the network’s reference server software. The serious one was an integer overflow in the payment engine. According to the report, it had been in the code since the current engine was written in 2015, and it went unnoticed until a researcher submitted it through the XRPL bug bounty programme on 22 September.
The submission was credited to Cayden Liao and Veria AI. Cryptonomist describes Veria AI as a security system built by Veria Labs and says it flagged the issue on 21 September. The reporters rated their finding Major. RippleX, Ripple’s engineering arm, reproduced it the same day and confirmed that the minted XRP was genuinely spendable. It then raised the rating to critical.
The fix was written and reviewed privately and shipped on 25 September as an emergency release. By the end of that day more than 80 per cent of validators on the default Unique Node List (UNL) had upgraded. The developers say there is no evidence anyone exploited the flaw on a public network. The bounty amount has not been disclosed.
The same release fixed a lower-severity bug in Batch transaction handling. It had first been found during a Sherlock Attackathon, a public competitive audit, and rated low. Re-checking showed the original fix was incomplete, and its fix amendment went live on Mainnet on 9 October.
The technical picture
This is a classic bug, which is exactly why it matters. When a single payment consumes many order-book offers in one pass, the engine totalled what the buyer owed using plain 64-bit addition and never tested for overflow. Every individual offer was legitimate. Several hundred offers, each demanding an absurd quantity of XRP for a minuscule quantity of some token, could push that total past the 64-bit limit so that it wrapped round to a tiny number. Sellers were still credited in full, but the buyer paid only the wrapped figure. The difference was XRP that should never have existed.
Two safeguards failed as well. The ledger’s “no XRP created” invariant used the same unchecked arithmetic, so it wrapped identically. The per-account limit only triggers when one account exceeds the entire supply, and spreading the proceeds across hundreds of accounts kept each balance under it. According to Veria Labs, as reported by Cryptonomist, one transaction could have produced about 18.45 trillion XRP. The developers put the real cost to an attacker at a few hundred XRP in recoverable reserves, plus fees.
The process decision is what interests me most. The XRP Ledger normally changes transaction rules by amendment: validators vote, and a change only takes effect after holding more than 80 per cent support for two weeks. Because the code is open source, sending the fix through that route would have advertised the bug for weeks before it took effect. So the team shipped the fix as a direct change for the first time in more than a decade, and published binaries without source code until disclosure. That attracted open-source criticism. Mayukha Vadari of RippleX explained the thinking on X, saying “things have changed with AI” when it comes to patches being reverse engineered.
Why it matters for UK organisations
The direct exposure in the UK falls on cryptoasset businesses registered with the Financial Conduct Authority and on firms that list, hold or settle XRP, or run XRPL infrastructure. If the flaw had been exploited, freshly minted tokens could have reached exchanges before anyone noticed. Anyone operating xrpld nodes must be on 3.4.1 or later, because older servers are now amendment blocked and cannot stay in sync with the network.
The wider lesson is for every organisation that runs a bug bounty or vulnerability disclosure programme. This is a clear public example of an AI-assisted submission producing a genuine critical finding, at a time when many programmes are swamped with low-quality automated reports. For UK researchers using AI tooling, it is also a reminder that a defined scope and safe harbour still matter. Until the Computer Misuse Act gains a statutory defence for good-faith research, authorisation is what protects them.
Expert view
Three things stand out. First, triage worked. The reporters called it Major, and the vendor reproduced it the same day and upgraded the rating. In my experience, programmes that down-rate by reflex damage researcher relationships far more than ones that occasionally over-rate.
Second, the invariant failure is a lesson for every engineering team. A control built on the same arithmetic as the code it polices is not independent. When we test payment and ledger systems, reconciliation logic that shares assumptions with the main code path is one of the first places I look.
Third, the claim that critical fixes can no longer be hidden applies well beyond crypto. Patch diffing is not new, but if AI shortens the time from fix to working exploit, quiet patches in routine releases offer little cover. This approach worked only because validator operators upgraded on day one. I also welcome the team’s new commitment to retest every finding marked as fixed against the release candidate before closing it, since the Batch bug showed a fix everyone believed was in place simply was not.
What to do now
- Patch XRPL infrastructure. UK firms running xrpld should confirm every node is on 3.4.1 or newer (Cyber Essentials: security update management).
- Review bounty triage. Make sure AI-assisted reports get a reproduction attempt rather than automatic rejection, and that severity can be raised as well as lowered.
- Retest before closing. Reproduce each original finding against the release candidate, whether it came from an audit, a bounty or an internal red team.
- Audit your safety checks. Look for invariants and reconciliation controls that reuse the logic of the code they are meant to verify.
- Prepare an emergency release route. Agree it with key stakeholders in advance, in line with NCSC vulnerability disclosure guidance.
Bottom line
A decade-old overflow that could have broken the XRP supply cap was found by a bounty hunter working with an AI tool, confirmed the same day and patched within three days, with no sign of exploitation. For UK security teams the lessons are about process: triage that listens, safeguards that are genuinely independent, and patch plans that assume attackers can read a fix as quickly as defenders can ship it.
