An AI agent found what humans missed for 11 years

A security firm’s AI agent located and weaponized a flaw that had sat untouched in the XRP Ledger’s core payment code since 2015, forcing RippleX to break with a decade of protocol-upgrade procedure to shut it down before the exploit could become public knowledge. The find matters less because of the dollar figure attached to it and more because of who found it: Veria Labs co-founder Cayden Liao said the bug was located and turned into a working exploit entirely by an AI agent, which he called the largest bounty ever paid for a vulnerability discovered that way, according to The Block.

RippleX’s own engineering leadership has since framed the episode as evidence that automated vulnerability hunting is now fast enough to change how critical patches get shipped, not just how they get found.

Key Takeaways

  • Veria Labs’ AI agent found a 2015-era overflow bug in the XRP Ledger payment engine and built a working exploit capable of minting roughly 18 trillion XRP, about 184 times the token’s 100 billion supply, in a single transaction, per The Block.
  • RippleX paid Veria Labs the bug bounty program’s maximum $250,000 payout.
  • Developers shipped the fix in xrpld 3.4.1 on Sept. 25, just three days after disclosure, letting it activate per-server as validators upgraded instead of waiting on the standard two-week, 80%-support amendment vote, a first in more than ten years of XRPL amendments.
  • The patch’s source code was published roughly two weeks after the compiled binaries went to validators, drawing criticism from Cyber Capital founder Justin Bons.
  • The disclosure report found no evidence the bug was ever exploited on a public network.

How the overflow actually worked

The bug lived in how the payment engine totals amounts owed when a single payment consumes many order-book offers at once. XRP balances are stored as 64-bit integers with a fixed ceiling, and the engine’s addition logic had no overflow check, so a sum large enough would wrap around to a tiny number instead of erroring out, according to CoinMarketCap.

An attacker could have opened a few hundred accounts, had each list a tiny fraction of some token for sale at an absurdly inflated XRP price, then closed every sale in one payment. Each seller wallet would have been paid in full while the buyer wallet was charged “only a few hundred drops plus the fee,” per the disclosure report cited by The Block. Two independent safeguards should have caught this and didn’t: the ledger’s invariant check, meant to confirm no transaction creates XRP, summed balance changes with the same unchecked arithmetic and wrapped around identically, while a separate check on single-account balances never triggered because the minted XRP was spread across hundreds of wallets, per CoinMarketCap. The exploit itself required no real capital, just a few hundred XRP in recoverable reserves plus ordinary fees.

The same xrpld 3.4.1 release also patched a second, unrelated bug in Batch, a feature that hadn’t yet gone live. That fix carried no minting risk: a successful attack “does not gain anything on-chain,” per The Block’s report, only a permanently malformed record capable of breaking indexers, explorers and SDKs that read the ledger.

Why RippleX skipped its own amendment vote

Rule changes on the XRP Ledger normally require an amendment, which activates only after more than 80% of trusted validators support it for two straight weeks, a design meant to let every server switch over in lockstep. Here, the fix instead took effect on each validator the moment it upgraded, meaning patched and unpatched servers briefly ran different rules for the same payment, according to ETHNews.

“We judged a short upgrade window with this limited risk to be far safer than weeks of a publicly known, open exploit,” the disclosure report stated, explaining the decision to bypass the vote. More than 80% of validators on the default Unique Node List, the trusted set most servers follow, were running the patched version by the end of release day, Sept. 25, per both The Block and ETHNews. Because xrpld is open source, a standard release would have published the fix’s code for weeks before it actually activated, showing any attacker exactly what to target, the report added.

A closed-source tradeoff draws pushback

Validators received compiled binaries of the fix before its source code was public, with the code following roughly two weeks later. Cyber Capital founder Justin Bons argued on X that this meant “XRP has been running closed-source code for the last two weeks,” a framing RippleX engineer Mayukha Vadari pushed back on directly. “You can’t sneak a critical bug patch into a routine public release process, it’ll get spotted and reverse-engineered immediately,” Vadari replied, per The Block.

RippleX Head of Engineering J. Ayo Akinyele went further, saying the team now plans to expand both AI-assisted bug hunting and formal verification work. “AI is fundamentally changing how quickly vulnerabilities can be discovered,” he wrote. The XRP Ledger Foundation also moved to head off confusion about the episode, posting on X that despite headlines about an “18 trillion XRP” exploit, no XRP was actually created: “XRP’s supply was fixed at 100 billion when the XRP Ledger launched, and no transaction is allowed to create more. This bug was a way around” that cap, per the foundation’s thread cited by ETHNews.

The timeline, as reconstructed by ETHNews from the disclosure, ran fast: Veria Labs filed its report Sept. 22, RippleX reproduced the exploit and raised its severity from major to critical, engineers merged a fix by Sept. 23, and xrpld 3.4.1 shipped without a vote on Sept. 25. The full vulnerability report wasn’t made public until Oct. 9.

What the episode leaves open is whether AI-driven security research turns up more dormant arithmetic bugs like this one across other chains, and whether shipping binaries ahead of source code becomes a template other projects reach for the next time a critical, decade-old flaw surfaces.

Sources