XRP Ledger discloses patched payment flaw that could mint XRP

The XRP Ledger’s maintainers disclosed on October 9 that they had patched a critical payment-engine flaw capable of creating spendable XRP without a corresponding deduction elsewhere. The project says it found no evidence that the vulnerability was exploited on a public network, but that conclusion reflects the maintainers’ investigation rather than an independently published, chain-wide forensic audit.

The fix shipped in `xrpld` 3.4.1 on September 25, more than two weeks before this Coinburn edition. The later disclosure is the news event: operators coordinated the private repair before the underlying source code and exploit mechanics became public.

An overflow defeated two accounting checks

According to the XRP Ledger’s technical report, the problem arose when the payment engine added the XRP owed across many order-book offers. The calculation used a fixed-width integer without checking whether the total exceeded its maximum value. A deliberately constructed payment could make that sum wrap to a much smaller number.

The engine would then credit each offer owner for the full amount while charging the buyer only the wrapped total. A safety invariant intended to prevent XRP creation performed a similar calculation and could overflow in the same way. A separate per-account check was insufficient because the newly created XRP could be distributed across multiple accounts.

Maintainers said ordinary payments and trades could not accidentally reach the vulnerable path. Exploitation required specially priced offers and a payment designed to consume them together. The project reproduced the issue on a standalone server and confirmed that XRP created in the test could be spent in a subsequent payment.

The report says the faulty payment-engine code dated to 2015. That makes the bug approximately a decade old, but it does not establish that anyone knew about or used it during that period.

Why the repair bypassed the amendment process

XRP Ledger transaction-rule changes normally use amendments. Under that process, a proposed rule activates only after support from more than 80% of trusted validators has persisted for two weeks. The overflow repair instead became effective on each server as soon as its operator installed version 3.4.1.

Maintainers said a conventional amendment would have exposed the vulnerability in public source code while leaving it exploitable during the voting and activation window. The direct upgrade created a different risk: upgraded and unpatched servers could disagree over a malicious transaction while the network was transitioning.

The disclosure says operators on the default Unique Node List coordinated quickly and that more than 80% of those validators were running the patched release on September 25. That percentage covers validators on the default trusted list, not every server or validator that may participate in the wider network.

A second defect reached its mainnet fix

The same disclosure covered a separate validation flaw in the ledger’s Batch feature. That defect could have produced malformed ledger records, disrupted downstream software or caused differing server versions to disagree about a ledger. Maintainers said the affected Batch amendment had not activated when the issue was found, so no mainnet transactions or funds were affected.

Its repair, `fixBatchV1_2`, activated on mainnet on October 9. The public GitHub release record now tells server operators to use version 3.4.1 or newer because older versions are amendment-blocked and cannot remain synchronized with the upgraded ledger.

What remains uncertain

The primary records establish the vulnerable code paths, the privately coordinated release, the Batch-fix activation and the maintainers’ test results. They do not independently prove that every historical transaction was reviewed or that every infrastructure operator upgraded on September 25.

The episode therefore demonstrates both a successful coordinated response and the difficulty of repairing consensus software without advertising a working exploit. The next useful evidence would be a post-incident technical audit or reproducible ledger analysis testing the project’s finding that no public-network exploitation occurred.