Pesquisa verificada por fontes: OKX

What the bug was

The official vulnerability disclosure report on xrpl.org explains it in plain terms. When a payment buys through an order book, the engine takes all offers at the best price in one pass and adds up what the buyer owes. That sum used ordinary 64-bit integer addition with no overflow check. XRP balances are stored as integers with a fixed maximum, so if the total went past that maximum it did not raise an error; it wrapped around to a small number.

The engine still paid each offer owner the full amount of their offer, but charged the buyer only the wrapped total. The difference was new XRP that should never have existed.

Two safety checks should have stopped this, and neither did:

• The "no XRP created" invariant, which confirms a transaction does not make new XRP, added up balance changes with the same kind of 64-bit counter, so it wrapped around in the same way and saw only what looked like a normal fee.
• The per-account check only fails if one account holds more than the total supply. Spreading the new XRP across hundreds of accounts kept each balance under that limit.

The report says the overflow existed since the current payment engine was written in 2015, and the invariant check, added two years later, inherited the same unchecked arithmetic.

How an attack would have worked

According to the report, an attacker would create a few hundred accounts, have each one offer a tiny amount of some token in exchange for a very large amount of XRP, and then send one payment that buys through all of those offers at once. Each seller account receives its full XRP; the buyer pays only a few hundred drops plus the fee. The real cost was a few hundred XRP in account and offer reserves, which are refunded when the objects are removed.

Cayden Liao of the security firm Veria Labs, which found the bug, said on X that a single exploit transaction could have created about 18 trillion XRP, which by his count is about 184 times the total supply. Liao said Veria's AI agent found the bug and built a working exploit, and that Ripple paid the bug bounty program's top award of $250,000, as reported by The Block.

The report stresses that this could not happen by accident: it needed hundreds of offers priced in a way no real trader would use. It also rejects a second idea from the original report, that such offers could block other people's payments, because those offers would always sit at the bottom of the book below real liquidity.

The timeline

Why the fix skipped the amendment vote

Normally a change to how transactions are processed ships switched off. It takes effect only after more than 80% of trusted validators support it for two weeks, so every server switches at the same ledger. The report says this fix took effect on each server as soon as it upgraded, the first time a transaction-processing change has shipped that way since the amendment system was introduced.

The reasoning: xrpld is open source, so any normal release would have shown attackers exactly where the bug was, weeks before the fix switched on. The trade-off was a short window in which upgraded and older servers followed different rules. Because only an exploit transaction could reach that code path, the developers judged a brief risk of disagreement, or even a network halt, safer than weeks of a public, open exploit. They add that this works only for the most severe bugs and does not change how protocol changes are normally made.

That reasoning has critics. The xrpld 3.4.1 release notes said the source code would not be published yet because of the security-sensitive fix. Justin Bons of Cyber Capital wrote on X that XRP had been "running closed-source code" for two weeks, according to The Block; RippleX engineer Mayukha Vadari replied that critical patches can no longer be hidden in a routine public release because AI tools would reverse-engineer them immediately.

The second bug: Batch transactions

The same release fixed a separate flaw in Batch, a feature that lets one account submit up to eight transactions as one unit. A hand-crafted Batch transaction could wrap inner transactions in the wrong field, and servers on different versions could disagree on whether it was valid, which might have stalled the ledger. Batch was not active on Mainnet when this was found, so no funds were at risk. The fix amendment and Batch itself both went live on 9 October, and servers older than 3.4.1 are now amendment-blocked, meaning they can no longer keep up with the network.

What it means for you

• If you hold XRP on an exchange or in a wallet: nothing to do. The developers found no sign of exploitation, and XRP's supply has not changed. The XRP Ledger's own documentation states that no more than the original 100 billion XRP can be created.
• If you run an XRPL server or build on XRPL: you must be on xrpld 3.4.1 or later to stay in sync, per the release notes.
• Market reaction: small. On Binance, XRPUSDT traded at $1.4073 at about 18:50 UTC on 11 October, up 0.21% over 24 hours, with a range of $1.3872 to $1.43.
• The bigger lesson: this is the second "decade-old bug found with AI help" story in a few weeks, after the Liquid sidechain exploit. RippleX head of engineering J. Ayo Akinyele said the team will expand AI-assisted bug hunting and formal verification. For long-running blockchains, old code is no longer safe just because it is old.

How to act on this

Security news like this is a reason to check where you keep XRP, not to trade it. If you buy or sell XRP on a centralized exchange, use one with deep XRP order books and working withdrawals, and keep long-term holdings in a wallet you control. OKX lists XRP spot and perpetual markets; signing up with code nexu888 returns 40% of trading fees, settled hourly (OKX profile). For leveraged XRP trading, check the funding-rate board first, because news-driven spikes are when funding and liquidations move fastest.

Quick answers

Was the XRP Ledger hacked? No. The bug was found by a security researcher, fixed on 25 September 2026, and the developers say there is no evidence it was ever exploited.

Did the XRP supply change? No. The flaw could have created XRP beyond the 100 billion cap, but it was not used, and the supply is unchanged.

Do I need to move my XRP? No action is needed for holders. Only server operators must upgrade to xrpld 3.4.1 or later.

Who found the XRP bug? Cayden Liao and Veria Labs reported it through the XRPL bug bounty program; Liao says an AI agent found it.

Why was the fix released without source code? Publishing the code would have revealed the bug before most servers were patched. The source was published on 9 October with the disclosure report.

Limits of this article

Technical details and dates come from the XRPL vulnerability disclosure report and the xrpld 3.4.1 release notes on xrpl.org; the 18 trillion XRP estimate, the $250,000 bounty and the X exchanges are reported by The Block and were not verified against each original post. Price data is a single Binance snapshot. This is not investment advice. Partner links may earn NexuAlpha a commission paid by the exchange, at no extra cost to you.