XRP Ledger Reveals Decade-Old Bug That Could Create XRP
XRP Ledger maintainers patched a long-dormant payment-engine flaw and strengthened supply checks after researchers demonstrated unauthorized XRP creation in testing. Image: XRP Ledger
Technology & Security

XRP Ledger Reveals Decade-Old Bug That Could Create XRP

XRP Ledger disclosed a payment-engine flaw dating to 2015 that could create spendable XRP; a September patch closed it, with no known public-network exploitation.

Make us preferred on Google

Key Notes

  • XRP Ledger disclosed a payment-engine flaw dating to 2015 that could create XRP outside the network’s supply rules.
  • Maintainers patched the bug on September 25 and found no evidence that it was exploited on any public network.
  • A separate Batch validation fix activated on October 9, and server operators must run xrpld 3.4.1 or newer.

XRP Ledger maintainers have disclosed a critical payment-engine vulnerability that could have allowed an attacker to create and spend XRP outside the network’s supply rules. The flaw appears to date back to 2015, but was patched on September 25. The October 9 disclosure says investigators found no evidence that it was exploited on any public network.

The security report credits Cayden Liao and Veria AI with identifying the issue through the XRPL bug bounty program. RippleX engineers reproduced the behavior on a standalone server and in unit tests, confirmed that the newly created XRP could be spent, and raised the finding’s severity to critical.

The disclosure also covers a separate flaw in the Batch transaction feature. Both fixes shipped in xrpld 3.4.1, although they followed different activation procedures. The XRP-creation bug affected version 3.4.0 and earlier; the vulnerable Batch functionality had not been enabled on Mainnet when its problem was identified.

An Accounting Error Defeated Two Safety Checks

The XRP flaw involved the arithmetic used when a payment consumes multiple offers from the ledger’s order book. Individually acceptable amounts could add up to more than the software’s integer counter could represent. Instead of rejecting the calculation, the counter wrapped around to a much smaller number.

That mismatch could let the engine credit offer owners with the full amounts while charging the buyer only the smaller total. The resulting XRP would appear in ordinary accounts and could be transferred, traded or sent to an exchange, according to the report.

XRPL already had an independent safety check intended to prevent transactions from creating XRP. Its invariant checks enforce rules including that transactions cannot increase the XRP supply and may destroy XRP only through fees. In this case, however, the supply check used the same vulnerable arithmetic and could overlook the discrepancy.

A separate limit on each account’s balance also failed to catch the problem because the unauthorized XRP could be distributed across many accounts. The report says ordinary payments and trades could not accidentally trigger the flaw: exploitation required deliberately constructed offers and a matching payment.

The age of the code is therefore important, but does not establish a history of unauthorized issuance. Investigators believe the error originated with the payment engine written in 2015. Their findings demonstrate an exploitable software defect, while their review found no evidence of its use on a public network.

The Patch Reached Validators in September

The bounty report arrived on September 22. Engineers reproduced the issue that day, developed and reviewed a fix, and included it in the September 25 security release. More than 80% of validators on the default Unique Node List were running the patched version on release day, according to the disclosure.

Version 3.4.1 rejects overflowing calculations when combining offers and payment paths. It also gives the supply-safety check a wider counter, reducing the chance that a similar accounting error could evade that protection through another route.

The release initially distributed patched software without publishing the source code for the fix. The October 9 report says the source has now been published, alongside the explanation of the vulnerability and the response.

Why Maintainers Used an Emergency Upgrade

XRPL normally coordinates changes to transaction processing through validator amendments. A proposed rule must retain support from more than 80% of trusted validators for two weeks before activation, allowing servers to switch behavior together.

The overflow fix instead took effect as soon as each server upgraded. Maintainers judged that publishing the repair while leaving the vulnerability active during the normal voting period would expose the network to an unacceptable risk of unauthorized XRP creation.

That decision carried a different risk: an exploit submitted while servers ran different versions could produce disagreement over ledger contents, potentially halting validation. The report says XRPL Foundation members, RippleX and validators agreed that a short upgrade window was preferable to leaving the known vulnerability open for weeks.

A Separate Batch Flaw Was Fixed Before Activation

The Batch issue concerned how grouped transactions were packaged. Different server versions could disagree over whether a malformed wrapper was acceptable, threatening network continuity and creating records that downstream software could not parse correctly.

That flaw did not let an attacker bypass transaction signatures or balance checks. The report says no funds were lost, no private keys were compromised and no Mainnet transactions were processed incorrectly. Validators delayed the feature so its corrective amendment could activate first; both the fix and Batch functionality became enabled on October 9.

All server operators must now run xrpld 3.4.1 or newer to remain synchronized. Maintainers also plan to require every security finding marked as fixed to be tested again against the release candidate before it is closed.

The work adds to the network’s broader security agenda, including the quantum-defense roadmap previously covered by CoinScreamer. The immediate finding concerns payment accounting: the repair is deployed, while the disclosure explains how a long-dormant error escaped safeguards and prompted an exceptional upgrade.

Disclaimer: CoinScreamer is an independent media brand owned and operated by NuvexMedia LLC, publishing news, research, and market insights on digital assets and related technologies. NuvexMedia LLC invests in and collaborates with companies across the digital asset, blockchain, and technology sectors. These relationships do not influence CoinScreamer’s editorial coverage, and the publication maintains full editorial independence to provide accurate, timely, and objective information. © 2025 NuvexMedia LLC. All rights reserved. This content is for informational purposes only and should not be considered legal, tax, investment, financial, or other professional advice.

News, Technology & Security