XRP Ledger Emergency Patch Closes Decade-Old Flaw That Could Have Created Spendable XRP

What to Know

• A flaw in the XRP Ledger’s payment system could have allowed attackers to create and spend new XRP without paying for it.
• The vulnerability is believed to date to 2015 and would have challenged XRP’s fixed supply model.
• All 100 billion XRP were created when the ledger launched in 2012, and the software is intended to prevent any additional XRP from being added.
• The issue was found by researcher Cayden Liao and Veria AI and internally reported on Sept. 22.
• RippleX reproduced the attack on a standalone server and confirmed that the newly created XRP could be spent in a later transaction.
• RippleX said it found no evidence that the flaw was exploited on any public network.
• The fix was shipped in xrpld 3.4.1, the ledger’s server software, on Sept. 25.
• The attack involved the XRP Ledger’s built-in exchange, where accounts can post offers to swap one token for another.
• The method could have used hundreds of accounts, with each receiving XRP while the buying account paid almost nothing because of a counting error.
• The researchers’ method needed only a few hundred XRP to open the accounts, most of which could be recovered, plus transaction fees.

XRP Ledger Patch Addresses a Serious Supply-Risk Scenario

The XRP Ledger has received an emergency software fix after researchers demonstrated a payment flaw that could have allowed an attacker to create spendable XRP without properly funding the transaction. The vulnerability was especially sensitive because XRP’s market structure is built around a fixed supply. All 100 billion XRP were created when the ledger launched in 2012, and the system is designed so that no more XRP can ever be added.

The issue, believed to date to 2015, was rooted in the ledger’s payment and exchange mechanics. In practical terms, the flaw could have let an attacker generate XRP from nothing and later move or sell that XRP, undermining a core assumption behind the asset’s supply discipline. RippleX, Ripple’s developer arm, said it found no evidence that the vulnerability was exploited on public networks.

The bug was found by researcher Cayden Liao and Veria AI and was internally reported on Sept. 22. Engineers at RippleX reproduced the attack on a standalone server, confirming that the XRP created through the method could be spent in a later transaction. Developers then shipped a fix in xrpld 3.4.1, the XRP Ledger server software, on Sept. 25.

How the Built-In Exchange Became the Attack Path

The vulnerability involved the XRP Ledger’s built-in exchange, a feature that allows accounts to post offers to swap one token for another. This exchange functionality is a central part of the network’s architecture, letting users route value through order books and token pairs directly at the protocol level rather than relying only on external trading venues.

In the demonstrated attack path, an attacker could theoretically open hundreds of accounts. Each account would post an offer to exchange a tiny amount of a token for an unusually large amount of XRP. The attacker would then submit a single payment designed to buy all of those offers at once. Because the total amount of XRP owed would become too large for the software to count correctly, the system could pay the selling accounts in full while charging the buying account almost nothing.

That accounting mismatch is what made the flaw so serious. The attacker’s receiving accounts could end up holding XRP that had not previously existed. Since the newly created XRP could then be spent in a later transaction, the vulnerability was not merely a display bug or a temporary ledger inconsistency. RippleX’s internal reproduction confirmed that the balances generated by the attack path could become economically meaningful if exploited.

Why Existing Safeguards Did Not Catch It

The XRP Ledger includes a post-transaction check intended to make sure that no new XRP has appeared after a transaction is processed. Under normal circumstances, that kind of accounting check is critical for preserving the fixed supply. In this case, however, the check would have relied on the same miscounted total that caused the problem, meaning it could miss the creation of new XRP.

A separate protection limiting how much XRP a single account can receive also would not have solved the issue. The demonstrated method spread the XRP across hundreds of accounts, keeping each recipient from triggering that account-level control. This made the vulnerability more difficult to detect through a simple single-account balance limit.

The researchers’ approach also did not require a large capital commitment. It needed only a few hundred XRP to open the many accounts involved, most of which could be recovered, plus transaction fees. That low operational threshold would have made the flaw particularly concerning if it had been known to malicious actors before the patch was released.

Fixed Supply Was the Central Concern

For XRP holders, validators, institutions, and infrastructure providers, the most important issue is the fixed supply promise. XRP’s token economics depend on the idea that the full supply was created at launch and that the ledger cannot mint more. A vulnerability that could create new spendable XRP, even if not exploited publicly, directly touches that foundational property.

If attackers had been able to create XRP and sell it on exchanges, market participants would have faced dilution risk from tokens that should not exist. Such a scenario could have damaged confidence in ledger-level accounting, particularly among institutions that use or evaluate the network with the understanding that the supply cap is enforced by code.

RippleX’s statement that it found no evidence of exploitation on public networks is therefore an important part of the incident. The absence of detected exploitation does not make the flaw minor, but it does shape the market impact. A discovered and patched vulnerability is different from an exploited one that leaves uncertain balances, exchange deposits, or historical transactions to unwind.

Emergency Fix Shipped Before Full Disclosure

Developers released the fix in xrpld 3.4.1 on Sept. 25 without initially disclosing the exact nature of what it repaired. That approach is common in high-severity infrastructure security events, especially when public details could help attackers reproduce the issue before enough network participants update their software.

For decentralized networks, patch coordination can be delicate. Server operators, validators, exchanges, wallet services, and other infrastructure providers may all need time to upgrade. If a bug affects consensus-critical or monetary-accounting behavior, early disclosure can create a race between defenders applying the fix and attackers trying to exploit the weakness. Quiet patching before detailed publication is often used to reduce that risk.

The case also highlights the complexity of mature blockchain systems. XRP Ledger has been operating for years, and the vulnerability is believed to date to 2015. Long-lived codebases can contain deep edge cases that are difficult to identify through routine testing, especially when a bug only emerges from a rare combination of payment routing, exchange offers, account distribution, and numerical accounting behavior.

AI-Assisted Security Research Continues to Surface Old Crypto Bugs

The XRP Ledger incident arrives amid a broader wave of long-hidden crypto security issues being surfaced with AI assistance. Since July, researchers and developers have dealt with multiple significant flaws across the digital asset ecosystem, including the Coldcard wallet bug behind the theft of at least 1,367 BTC and vulnerabilities that forced Core Lightning to tell bitcoin node operators to disconnect.

That pattern reflects a changing security landscape. AI tools can help researchers search codebases, reason through unusual execution paths, and test combinations that may have been overlooked during earlier review cycles. At the same time, the same capabilities can potentially help attackers find vulnerabilities faster. For blockchain networks, where software bugs can have direct financial consequences, the pressure to audit legacy code is increasing.

FXCOINZ views this type of event as a reminder that fixed-supply assets rely on more than monetary policy language. They rely on implementation details, edge-case handling, validator behavior, and rapid coordination when something breaks. In XRP’s case, the important near-term facts are that the flaw was reproduced in a controlled environment, the fix was released in xrpld 3.4.1, and RippleX said no exploitation was found on public networks.

Market Impact Depends on Trust in the Patch

The immediate market implications are likely to depend on how confidently participants view the patch and the surrounding disclosure. Some traders may focus on the severity of the bug because it affected the possibility of creating XRP outside the intended supply rules. Others may focus on the absence of known public exploitation and the fact that the issue was fixed before broader technical details became widely actionable.

For infrastructure providers, the priority is software hygiene. Running current server software is essential when a flaw can affect monetary accounting. For holders, the incident reinforces the importance of validator and developer responsiveness. For institutions evaluating XRP Ledger, the event may prompt more questions about formal verification, exchange-path testing, and long-term review of legacy protocol logic.

No blockchain system is immune to software risk. What separates manageable incidents from systemic failures is detection, containment, communication, and adoption of patches across the network. The XRP Ledger vulnerability was serious because it touched the most sensitive layer of any token system: whether balances can be created outside the rules. The fix in xrpld 3.4.1 now becomes the key line of defense against the demonstrated attack path.

Frequently Asked Questions (FAQs)

What was the XRP Ledger bug?

The bug was a flaw in the XRP Ledger’s payment system that could have allowed an attacker to create and spend new XRP without properly paying for it. It was connected to a counting error in the ledger’s built-in exchange.

When did the vulnerability reportedly date back to?

The vulnerability is believed to date to 2015. That means it may have existed in the codebase for years before being identified and patched.

Who found the XRP Ledger vulnerability?

The issue was found by researcher Cayden Liao and Veria AI. It was internally reported on Sept. 22, after which RippleX engineers reproduced the attack on a standalone server.

Was the bug exploited on public XRP Ledger networks?

RippleX said it found no evidence that the flaw was exploited on any public network. The attack was reproduced in a controlled standalone environment, where engineers confirmed that the newly created XRP could be spent later.

How could the attack have created XRP?

The attack could have used hundreds of accounts placing offers on the built-in exchange. A single payment could then buy those offers at once, causing the software to miscount the total XRP owed and allowing accounts to receive XRP while the buyer paid almost nothing.

Why did the fixed supply of XRP matter in this incident?

All 100 billion XRP were created when the ledger launched in 2012, and the software is intended to prevent any more from being added. A flaw that could create spendable XRP would directly challenge that fixed-supply design.

What software version fixed the issue?

The fix was shipped in xrpld 3.4.1, the XRP Ledger server software. Developers released the update on Sept. 25 without initially disclosing the specific flaw it repaired.

Did the attack require a large amount of XRP?

The researchers’ method needed only a few hundred XRP to open the required accounts, most of which could be recovered, plus transaction fees. That relatively small requirement added to the seriousness of the vulnerability.

What should XRP Ledger operators take from this event?

Operators should treat current server software as essential security infrastructure. The incident shows why rapid patch adoption, ongoing code review, and careful testing of edge cases are critical for networks that enforce fixed token supplies.