XRP Ledger Vulnerability: Could It Have Minted XRP Out of Thin Air?

Overview

A critical XRP Ledger vulnerability that had remained in the payment engine for roughly a decade could theoretically have allowed an attacker to create spendable XRP beyond the ledger’s intended supply rules. XRPL disclosed the issue on October 9, 2026, after it was privately reported through the XRPL Bug Bounty Program on September 22. The vulnerability affected xrpld 3.4.0 and earlier versions and was fixed in xrpld 3.4.1, released on September 25.

The XRP Ledger vulnerability involved an integer overflow when a payment consumed hundreds of specially constructed order-book offers. Individual offer owners could receive their full XRP amounts while the buyer was charged only a small wrapped-around total. More seriously, the ledger’s existing “no XRP created” invariant used a similar arithmetic path and could overflow in the same way, preventing that safety check from detecting the discrepancy.

XRPL says it found no evidence that the vulnerability was exploited on any public network, and normal payments could not accidentally trigger it. The attack required deliberately engineered offers with economically unrealistic prices. Even so, the incident raises a deeper security question: a blockchain’s fixed monetary policy is only as strong as the software enforcing every balance transition.

Key Takeaways

• The bug appears to have existed since the current XRPL payment engine was written in 2015.
• A deliberately constructed transaction could theoretically have created spendable XRP.
• XRPL found no evidence of exploitation on a public network.
• The existing supply invariant could fail because it reproduced the same overflow behavior.
• xrpld 3.4.1 added checked arithmetic and a stronger independent supply check.

What Was the XRP Ledger Vulnerability?

The vulnerability sat inside the XRP Ledger payment engine's handling of order-book liquidity. When a payment moves through multiple offers, the engine has to calculate how much XRP the payer owes in total. Each individual amount could be valid, but the aggregate calculation used a 64-bit integer without sufficient overflow protection.

Under ordinary conditions this was effectively unreachable. XRP’s normal supply and real market prices do not come remotely close to the numerical boundary required to overflow the counter. The problem emerged only when an attacker deliberately constructed hundreds of offers in which each account requested an extremely large amount of XRP for a tiny amount of another token.

A malicious flow could look roughly like this:

• Create several hundred controlled accounts.
• Place deliberately unrealistic offers from those accounts.
• Construct one payment designed to consume those offers together.
• Push the aggregate XRP calculation beyond the integer limit.
• Cause the total to wrap around to a much smaller number.

The engine could then credit the offer owners individually while charging the buyer only the overflowed total. Because the attacker could control the offer-owner accounts as well, the difference effectively became new XRP.

XRPL engineers reproduced the attack locally and confirmed that the resulting XRP could subsequently be transferred. The issue was consequently raised from Major to critical severity.

Could the XRP Ledger Vulnerability Really Create XRP?

Yes, theoretically. This was not merely an accounting-display error. XRPL's technical disclosure says the exploit could have created XRP that behaved like ordinary XRP after the malicious transaction was validated. Those balances could have been moved, traded or sent to exchanges.

That does not mean XRP was historically overissued. XRPL reports that it found no evidence that the exploit occurred on any public network. The difference between those two statements is essential: the vulnerability could violate the intended supply constraint, but there is currently no confirmed historical supply event associated with it.

The attack also could not occur accidentally during normal DEX trading. The order-book offers had to be priced so unrealistically that normal market liquidity would execute before reaching them. A payment also had to be intentionally constructed to consume enough of those offers together to trigger the overflow.

This is therefore best understood as a low-probability execution path with extremely high theoretical impact, rather than an error that ordinary XRP users might have unknowingly triggered.

Why Did XRPL's Supply Safety Check Fail?

The most technically important part of the incident is not simply that an integer overflow existed. Mature financial software often contains multiple defensive layers designed to catch exactly that kind of unexpected result.

XRPL had one: a transaction invariant intended to ensure that a transaction could not create XRP. In principle, even if the payment engine made an accounting error, the invariant should have noticed that total XRP balances increased and rejected the transaction.

It did not.

The reason is a classic failure of supposedly independent safety systems. The invariant calculated net XRP changes using a similar type of unchecked arithmetic. When the payment engine overflowed, the invariant calculation could overflow in the same direction, making the resulting transaction appear to have changed XRP supply only by the ordinary transaction fee.

A safety check is not truly independent when it can reproduce the same failure mode as the system it is checking.

A second protection checked whether an individual account balance exceeded the total XRP supply. That also failed to stop the attack because the newly created XRP could be distributed across hundreds of accounts, keeping each individual balance below the limit.

The remediation therefore addressed both the immediate bug and the defensive architecture. xrpld 3.4.1 added explicit overflow checks when amounts are aggregated across offers and payment paths. XRPL also changed the no-XRP-created invariant to use a wider counter that cannot wrap around under the same conditions.

Why Did a 2015 Bug Stay Hidden for So Long?

The answer lies partly in the difference between realistic economic values and theoretical computer limits. Individual XRP payments operate many orders of magnitude below the range required to overflow a 64-bit sum. A normal trader could use XRPL for years without creating anything resembling the malicious numerical conditions.

This made the flaw difficult to expose through routine usage. The vulnerable logic could behave correctly across billions of normal operations while still failing catastrophically at an artificial boundary.

The vulnerability also demonstrates why long-lived blockchain code should not automatically be considered safe simply because it has operated for many years. Production history is useful evidence, but it mainly tests common states. Attackers deliberately search for states that normal users never create.

XRPL credited its Bug Bounty Program with finding the issue and has outlined a broader defense-in-depth approach that includes independent audits, public attackathons, fuzzing, AI-assisted red teaming and formal verification. It is also adding re-verification of security fixes against release candidates before findings are formally closed.

That approach matters because the lesson from this incident is not that mature code cannot be trusted. It is that mature code still requires adversarial testing against assumptions developers stopped questioning years earlier.

What Does the Bug Mean for XRP's Fixed Supply?

XRP began with a defined initial supply of 100 billion tokens, with no protocol mechanism analogous to proof-of-work mining that continuously creates additional XRP. Transaction fees are destroyed rather than paid to validators, so the intended supply path is non-inflationary.

The XRP Ledger vulnerability exposes an important distinction between monetary policy as a rule and monetary policy as software enforcement.

A blockchain specification may state that new XRP cannot be created, but nodes ultimately enforce that property through code. If balance-transition logic can be manipulated into violating the rule, then the economic policy itself can fail even though the documented policy has not changed.

This incident did not demonstrate that XRP’s actual circulating supply was secretly increased. XRPL says no public-network exploitation was found. But it did demonstrate that, before the patch, there was a theoretical execution path capable of bypassing one of the ledger’s most fundamental monetary constraints.

That makes this vulnerability more consequential than a temporary RPC outage or a node-connectivity problem. A network can tolerate certain infrastructure disruptions without compromising asset integrity. A bug capable of generating spendable units touches the accounting foundation of the ledger itself.

Why the Fix Matters More Than the Absence of an Exploit

It is tempting to dismiss a vulnerability once investigators say it was never exploited. That would miss the more useful security lesson.

XRPL's response timeline was relatively compressed: the issue was reported and reproduced on September 22, the fix was developed and reviewed over September 22–23, merged into the 3.4.1 release branch, and released on September 25. XRPL reported that more than 80% of default Unique Node List validators were running the protected version on the same day.

The payment-engine fix also took effect directly with the software upgrade rather than waiting for the normal amendment activation process. That was possible because rejecting arithmetic overflow was treated as fixing undefined or unsafe behavior rather than introducing a new intended transaction rule.

For blockchain security, disclosure timing is part of the defense. Publishing the exploit before validators were protected would have turned a theoretical vulnerability into operational instructions for attackers. XRPL therefore disclosed technical details after the patched version had already propagated.

Risks and Limitations

The incident is serious, but several boundaries should remain clear.

• No confirmed inflation event: XRPL says it found no evidence of exploitation on a public network.
• No accidental trigger: normal payments and realistic order books do not reach the necessary values.
• Patch adoption matters: server operators are expected to run xrpld 3.4.1 or newer.
• One fix does not prove complete safety: other old arithmetic assumptions still warrant adversarial testing.
• Historical absence of abuse cannot replace formal verification: some classes of bugs are too unusual to emerge through normal network activity.

Another limitation is retrospective certainty. Investigators can analyze ledger history and known exploit patterns, but proving that a vulnerability was never used is inherently different from proving mathematically that it could not have been used. The official conclusion is therefore appropriately framed as no evidence found, rather than an absolute claim about every historical state.

MEXC View: Fixed Supply Is a Software Security Property

A blockchain's monetary policy is not secured by a supply number written in documentation alone. It is secured by the software that validates every balance change, transaction path and ledger state.

The XRPL incident illustrates why this distinction matters. The protocol's intended rule prohibited creating new XRP, yet a flaw in arithmetic could theoretically have violated that rule. More importantly, the defensive invariant designed to catch supply creation initially shared the same failure mode.

For mature blockchain networks, security therefore needs to move beyond testing whether normal transactions behave correctly. Independent invariants, fuzzing, adversarial boundary testing and formal methods become increasingly important precisely because the most damaging vulnerabilities may exist in code paths ordinary users never touch.

The metric worth watching after this disclosure is not XRP price reaction. It is whether XRPL's expanded verification processes consistently find and isolate similar classes of latent protocol risk before attackers do.

The Decade-Old Bug Was Critical, Not a Proven XRP Inflation Event

The XRP Ledger vulnerability deserves the “critical” description because it could theoretically have undermined one of XRPL's most fundamental guarantees. A carefully engineered payment could force a 64-bit arithmetic overflow, credit hundreds of offer owners with XRP and charge the buyer only a fraction of the aggregate amount. The newly created balances were spendable in XRPL's own reproduction of the attack.

But the second half of the story is equally important. XRPL found no evidence of public-network exploitation, the transaction required deliberately abnormal order-book conditions, and the vulnerability was patched in xrpld 3.4.1 before the technical details were publicly disclosed.

The incident therefore should not be rewritten as evidence that XRP's supply was historically inflated. Its significance is more structural. It shows that even a fixed-supply blockchain ultimately depends on software correctly enforcing monetary constraints under edge cases that may remain invisible for years.

The strongest takeaway from this XRP Ledger vulnerability is consequently about protocol engineering rather than token supply headlines. Monetary invariants need independent implementation, old code still requires adversarial review, and successful network operation over a decade does not eliminate the possibility of hidden boundary-condition failures. The bug did not prove that XRP had been overissued; it proved why supply integrity must be continuously verified.

Sources

XRPL official vulnerability disclosure:
https://xrpl.org/es-es/blog/2026/vulnerabilitydisclosurereport-bug-20261009

XRPL 3.4.1 release information:
https://xrpl.org/blog

想最快获取 MEXC 最新资讯？立即加入我们的官方电报群！
MEXC 平台：下载 App | 零手续费交易 | 立即购买 USDT 加入 MEXC 社群：X (Twitter) | Telegram | Discord
获取资讯：新手学院 | 服务条款 | MEXC Blog | MEXC News
账户验证：了解 KYC | 如何进行 KYC

风险提示：本文内容仅供参考，不构成任何投资建议。数字货币市场波动较大，请根据自身情况审慎决策。