XRP Ledger developers have patched a critical payment-engine flaw that could have allowed an attacker to create spendable XRP far beyond the network’s 100 billion supply cap in a single transaction, according to a disclosure report by Veria Labs. The vulnerability had existed in xrpld code since 2015, though the report said there was “no evidence that this issue was exploited on any public network.”
The flaw was reported to RippleX on Sept. 22 and patched three days later in xrpld version 3.4.1. Veria Labs said more than 80% of validators on XRP Ledger’s default Unique Node List had installed the release on the day it was issued, limiting the practical window for an attack against the network.
Cayden Liao, co-founder of Veria Labs, said an AI agent identified the flaw and generated a working exploit. In a post on X, Liao estimated that one malicious transaction could have created roughly 18 trillion XRP—about 184 times the network’s original maximum supply—if it had reached a vulnerable network.
Payment calculation could wrap around
The vulnerability involved payments that consume multiple offers from XRP Ledger’s decentralized order book. Such transactions can match against many offers at once, requiring the software to total the amount of XRP paid across all of them.
According to Veria Labs’ report, that addition lacked an overflow check. In computing, an overflow occurs when a number becomes too large for the allotted data type; instead of producing the correct large value, the calculation can wrap around to a much smaller number.
An attacker could have used several hundred accounts to place offers selling a tiny fraction of a token for extraordinarily large XRP amounts. A single payment transaction could then consume those offers. The payment engine would credit each seller with the stated XRP amount, while the buyer’s calculated cost could wrap around to “only a few hundred drops plus the fee,” the report said. A drop is the smallest unit of XRP, equal to one-millionth of an XRP.
The error could have expanded XRP balances without properly debiting the attacker’s account. Veria Labs said a separate safeguard designed to detect newly created XRP used another addition operation vulnerable to overflow. As a result, the protocol’s internal supply check could also fail to recognize the artificial increase in balances.
The scale of the theoretical exploit placed it in a different category from a typical exchange compromise or bridge theft. Rather than stealing existing funds from a defined pool, the attacker could have introduced new spendable units into circulation, potentially undermining confidence in the ledger’s supply rules if those units reached trading venues or other network participants.
Fix bypassed the normal amendment timetable
RippleX’s patch took effect through server upgrades rather than XRP Ledger’s usual amendment process, Veria Labs said. Amendments typically alter network rules only after receiving more than 80% support from trusted validators for two weeks.
That process is designed to give operators time to review and deploy upgrades before a protocol rule becomes active. In this case, the security issue required a faster response: each server received the protection when its operator upgraded to xrpld 3.4.1.
Veria Labs described the approach as the first use of this upgrade-led activation path in more than a decade of XRP Ledger amendments. The decision reflects the practical trade-off in handling a vulnerability with a short remediation window: broad public discussion before a patch is widely deployed can give attackers enough technical detail to reconstruct the exploit.
Justin Bons, founder and chief investment officer of Cyber Capital, wrote on X that xrpld 3.4.1 had remained closed source for about two weeks before the code was published. Mayukha Vadari, a software engineer at RippleX, said rapid discovery and reverse-engineering concerns shaped the release process.
That sequence drew attention because open-source networks generally depend on public code review, while a temporary restriction on source availability limits independent examination. RippleX’s approach prioritized preventing exploitation while validator operators deployed the repair, then published the code after the urgent period had passed.
A second patch addressed the Batch feature
Version 3.4.1 also fixed a separate issue involving Batch, a feature that had not yet activated when researchers identified the first flaw. Veria Labs said the Batch vulnerability could have stalled the network under certain circumstances.
The report said an attacker would not gain assets on-chain through the Batch issue. Its potential impact involved creating a permanently malformed ledger record that could disrupt off-chain services such as indexers, blockchain explorers and software development kits. Those services interpret and organize ledger data for wallets, applications and users; malformed records can therefore create operational problems even when ledger balances remain intact.
Veria Labs said Batch and its fix activated on Friday, and that servers running older software versions can no longer remain in sync with the network. That outcome creates a strong incentive for remaining operators to update, since out-of-date servers cannot reliably track the current ledger state.
Liao said Veria Labs received the maximum $250,000 bounty for reporting the vulnerabilities. The reward reflects the potential severity of a flaw that reached the core accounting logic of a public blockchain rather than a peripheral application.
The incident also adds evidence that automated code analysis is becoming a practical part of vulnerability discovery. Liao’s account of an AI agent finding and exploiting the issue does not establish that automation can replace human security review, but it shows how quickly old arithmetic errors can be surfaced when researchers combine automated scanning with technical understanding of a protocol’s transaction rules.
XRP Ledger’s repair prevented the vulnerability from becoming a supply event visible to the market. The remaining questions center on whether other mature blockchain codebases contain similar integer-overflow risks in complex transaction paths, especially where multiple operations are aggregated and balances are checked through separate accounting routines.
Concerned about protocol risks after this XRP Ledger bug? Explore cross-chain payment dynamics in this cross-border payments analysis.
Disclaimer: The content on this page is provided for general informational purposes only and does not represent the views or financial advice of Toobit. We make no guarantees regarding the accuracy or completeness of this information and shall not be held liable for any errors, omissions, or outcomes resulting from its use. Investing in digital assets involves risk; users should independently evaluate their financial situation and the risks involved. For further details, please consult our Terms of Service and Risk Disclosure.
