Mentioned in This Article
1. A Flaw That Could Have Broken the Supply Cap
A vulnerability in the payment system of the XRP Ledger could have allowed an attacker to create large amounts of XRP without paying for it. The finding, laid out in a security report released on Friday, October 9, 2026, concerns one of the most basic promises of the network: that its supply is fixed and cannot grow.
The flaw is believed to date back to 2015, which means it sat unnoticed in the ledger's software for roughly a decade. RippleX, the developer arm of Ripple, said it found no evidence that the weakness was used against any public network. The issue has been repaired, and the report is a retrospective account of what could have gone wrong rather than a description of an attack that took place.
Even so, the episode drew attention because of the kind of rule involved. Software bugs that leak funds from individual users are serious, but a bug that lets new coins appear from nothing strikes at the monetary design of the entire system. For a network whose appeal to institutions rests partly on predictable scarcity, that distinction is significant.
The discovery also shows how long-lived code can hide problems in places that routine review does not reach. Blockchain software is open to inspection, yet a subtle arithmetic mistake in a rarely stressed code path can survive years of scrutiny, particularly when the conditions required to trigger it are unusual.
2. Discovery and Confirmation
The problem was identified by researcher Cayden Liao together with Veria AI, who reported it internally on September 22. RippleX engineers then set about testing whether the concern was real. They reproduced the attack on a standalone server, a private test environment that does not touch the live network, and confirmed that the newly created XRP could be spent in a later transaction.
That last point is the crucial one. A miscalculation that merely displays a wrong balance would be a cosmetic defect, but coins that can actually be spent again are real in every sense that matters to the ledger. By showing that the generated XRP was spendable, the engineers established that the flaw was not theoretical bookkeeping noise but a route to genuine inflation.
Reporting a flaw privately before it is made public is standard practice in security research. It gives maintainers time to prepare and distribute a repair so that attackers cannot exploit the weakness during the gap between disclosure and fix. In this case the timeline moved quickly, with a patched release available within days of the first report.
The involvement of an artificial intelligence security firm alongside an individual researcher also reflects a broader change in how vulnerabilities are located. Tools that read large amounts of code and test unusual input combinations can surface errors in places where manual audits tend to look less closely, such as the interaction between different parts of a transaction engine.
3. Why a Fixed Supply Matters
All 100 billion XRP were created when the ledger launched in 2012, and the software is built so that no further tokens can ever be added. Unlike networks that issue new coins to reward block producers, the XRP Ledger has no mechanism for minting. The total can only decline, as small amounts are destroyed through transaction fees.
That design is a core part of the asset's pitch. Banks, payment companies and other institutions that use the network for settlement rely on the assurance that the quantity of XRP cannot be inflated by anyone. A bug capable of generating billions of dollars worth of the token would have undermined that assurance, since holders could no longer be certain that the supply they were told about matched the supply that existed.
The potential market consequences are straightforward to imagine. Newly created coins that were sold into the market would have increased supply and pressured prices, while confidence in the ledger itself could have suffered. The fact that no exploitation was detected means those outcomes remain hypothetical.
4. How the Attack Would Have Worked
The weakness lay in the ledger's built-in exchange, a feature in which accounts post offers to swap one token for another. Payments can be routed across these offers, which lets a sender pay in one asset while the recipient receives another.
In theory, an attacker could open hundreds of accounts, with each one offering a tiny amount of a token in return for a very large amount of XRP. The attacker would then send a single payment designed to fill every one of those offers at once. The total amount of XRP owed across all of the offers exceeded what the software was able to count correctly. As a result, each selling account was credited in full, while the buyer was charged almost nothing.
In plain terms, the ledger paid out far more XRP than it took in. The shortfall was never recorded as a debt, so the extra coins simply appeared in the selling accounts, all of which the attacker would control and could then spend.
Amounts of this kind are a familiar source of trouble in financial software. Systems that handle very large quantities, or very small fractions, must make sure every intermediate figure fits within the range the program can represent. When a running total passes that range without being detected, the results can wrap around or be rounded in ways that favor one side of a trade. Such errors are easy to overlook in testing because ordinary activity never comes close to the limits.
5. Why the Safeguards Did Not Catch It
The ledger includes protective checks, and two of them might have been expected to stop this. After every transaction, the software verifies that no new XRP has come into existence. In this case, that check relied on the same miscounted total, so it saw nothing wrong and let the transaction stand.
A separate limit on how much a single account can receive also failed to trigger. Because the attacker would spread the created XRP across hundreds of accounts, no individual account crossed the threshold. The design of the attack, using many small participants rather than one large one, was well matched to slip beneath that control.
The lesson for engineers is that independent safeguards work best when they do not depend on the same underlying calculation. When a verification step and the operation it verifies share a flaw, the check can confirm the error rather than expose it.
This also illustrates why defense in depth is valued in systems that hold money. A single control, however well built, offers one point of failure, whereas several independent controls make it harder for one mistake to pass through unnoticed.
6. Low Cost to the Attacker
The method would not have required significant resources. An attacker would have needed only a few hundred XRP to open the accounts, and most of that amount could have been recovered afterward. Beyond that, the only expense was ordinary transaction fees.
This is what makes the flaw notable from a risk standpoint. The potential reward, billions of dollars of newly created tokens, was out of all proportion to the cost of attempting it. Weaknesses with that profile tend to be attractive to attackers once they become known, which is one reason the maintainers moved promptly to correct it before publishing details.
Security specialists often describe this as an asymmetric risk. The defenders must close every gap, while an attacker needs to find only one, and a cheap, repeatable method makes the exposure worse.
7. The Fix and Its Quiet Rollout
Developers released the correction in xrpld 3.4.1, the ledger's server software, on September 25. That was three days after the internal report. The release did not disclose which problem it addressed, a deliberate choice that avoids pointing attackers toward the vulnerability while node operators upgrade.
Node operators run the software that keeps the network in agreement, so the effectiveness of any patch depends on how widely it is adopted. Withholding the details until the fix had been out for a period of time is a common way to balance transparency with protection. The full explanation arrived only with this week's security report.
For users, no action to protect funds was described as necessary, since no exploitation was found. Operators of servers, however, are expected to run the updated release.
8. Part of a Wider Pattern of Hidden Flaws
The case joins a series of long-hidden security problems in crypto software that have come to light since July, with artificial intelligence tools playing a role in uncovering them. Among the examples cited are a bug in the Coldcard hardware wallet, linked to the theft of at least 1,367 BTC, and vulnerabilities that led Core Lightning to advise bitcoin node operators to disconnect.
Taken together, these incidents suggest that automated analysis is becoming effective at finding subtle errors that human reviewers missed for years. That is good news when the findings reach maintainers first, as happened here, but it raises the stakes for the industry, because the same techniques are available to people with harmful intentions.
For the XRP Ledger, the immediate matter is closed. The flaw has been fixed, the supply remains intact, and the project can point to a responsible disclosure process that worked as intended. The longer-term question is how many similar issues remain in mature codebases across the sector.
Responsible disclosure of this kind has become a hallmark of mature open-source projects. Researchers are encouraged to report privately, maintainers are expected to respond quickly, and public explanations follow once users have had time to update. The sequence seen here, from report to confirmation to patch to publication, follows that model closely.