XRPL Disclosed a Bug That Could Have Created XRP From Nothing: What the Report Says

On Oct. 9, 2026, XRPL.org published a vulnerability disclosure report describing a bug in the software that runs the XRP Ledger. The report says the bug could have let an attacker create spendable XRP that did not exist before. The fix has been out since Sept. 25, and the report says it found no evidence that anyone exploited the flaw on a public network. This article explains what the report says, who needs to act, and which parts rest only on the project's own account.

What the report describes

The report says the problem sat in the payment engine, the part of the software that matches a payment against offers in the ledger's built-in exchange. When a single payment crossed many offers, the engine added up the amounts using a fixed-size 64-bit number. A number that large can still run out of room, and when it does, the total wraps around to a tiny value. This is called an integer overflow.

According to the report, the wrapped-around total meant the buyer was charged a very small amount while the owners of the offers were credited in full. The difference would have appeared as new XRP. The report says this behavior affected xrpld 3.4.0 and earlier, and that the issue is believed to have been present since the current payment engine was written in 2015.

Cayden Liao and Veria AI reported the bug on Sept. 22, 2026 through the XRPL Bug Bounty, according to the report. It was first rated "Major" and then raised to critical by RippleX.

Why the usual safety check missed it

The XRP Ledger runs automatic checks, called invariants, after each transaction. One of them confirms that a transaction does not create XRP. The report says that check used the same unchecked arithmetic as the payment engine, so it overflowed in the same way and did not flag the problem. XRPL's documentation on invariant checking explains the general design.

What an attack would have required

The report says exploitation needed hundreds of deliberately mispriced offers plus a carefully built payment, and that it could not happen by accident. The cost to an attacker would have been account reserves and transaction fees. It also says the team tested a related scenario, in which someone clogs the order book with offers to disrupt trading, and found it not practical.

The report's central statement on impact reads: "We have found no evidence that this issue was exploited on any public network."

Why the fix was not an amendment

Most XRP Ledger changes to how transactions work arrive as amendments, which validators vote on and activate on a schedule. XRPL's amendments documentation describes that process. This fix shipped differently. The report says it took effect as soon as a server upgraded to xrpld 3.4.1 on Sept. 25, and that this is the first time since amendments were introduced, more than ten years ago, that a transaction-processing change was deliberately released this way.

The report gives two reasons: the severity of the bug, and the fact that publishing the fix in open source code for weeks before activation would have exposed the flaw. It acknowledges the tradeoff. Servers running different versions could disagree about a transaction, which could stall the network during the upgrade window. The report says more than 80% of validators on the default trusted list were already running 3.4.1 or later on Sept. 25, and that the approach does not change how the XRP Ledger makes protocol changes in general. The 3.4.1 source code was published on Oct. 9.

A second issue: Batch transaction validation

The same report covers a separate bug, reported on Sept. 18. It affected xrpld 3.3.0 and 3.4.0 when the BatchV1_1 amendment was active. Batch transactions bundle several inner transactions together, and each inner transaction had to be wrapped in a specific format that the server did not check. The report says this could have caused servers on different versions to disagree, or left permanently malformed records.

The report says neither Batch amendment had been active on Mainnet, so no accounts or funds were affected. It says Ripple and other validators changed their votes on BatchV1_1 to "no" on Sept. 23 and 24 to reset the amendment's clock. The fix, called fixBatchV1_2, and BatchV1_1 both activated on Mainnet on Oct. 9, 2026. Older servers are now amendment-blocked, which means operators must run 3.4.1 or newer.

What this means for different readers

• XRP holders: The report describes no step for holders to take.
• Exchanges and node operators: Servers must run xrpld 3.4.1 or newer to stay in step with Mainnet.
• Anyone tracking security practices: The report says the project's roadmap will add a re-verification step for every security finding marked as fixed.

What remains unverified

The report is the XRPL project's own account, and this article did not find an independent audit confirming its technical findings or its statement that no exploitation occurred. "No evidence found" is a statement about what the team searched, not proof that nothing happened. The report gives no count of affected accounts, and it says it found no evidence of exploitation. Nothing in it is a statement about XRP's price or market value, and this article makes no such claim.

Disclosure: This article summarizes XRPL.org's Oct. 9, 2026 vulnerability disclosure report, which is the project's own account and was not independently audited in the sources reviewed. The featured illustration is AI-generated and conceptual. This article is not financial, legal, or investment advice. AI-assisted research and writing. Cited sources, not AI alone, support the claims.