Create

would

when

<div class="light-yellow-block">
 <h2 id="strong-key-takeaways-strong"><strong>Key Takeaways</strong></h2>
 <ul>
  <li><strong>A payment overflow could have created spendable XRP.</strong></li>
  <li><strong>XRPL found no evidence the flaw was exploited.</strong></li>
  <li><strong>The patch shipped in xrpld 3.4.1 on September 25.</strong></li>
  <li><strong>Developers bypassed the normal amendment timeline to close the risk faster.</strong></li>
 </ul>
</div>
<h2 id="a-payment-calculation-could-produce-xrp-from-nothing">A payment calculation could produce XRP from nothing</h2>
<p>XRPL’s <a href="https://xrpl.org/blog/2026/vulnerabilitydisclosurereport-bug-20261009" rel="noopener noreferrer nofollow">October 9 vulnerability report</a> describes an integer-overflow flaw in the ledger’s payment engine. Under carefully constructed conditions, a payment that consumed many order-book offers could have credited accounts with XRP that the sender had not actually paid.</p>
<p>Each offer in the transaction could appear valid on its own. The failure arose when the engine added the XRP amounts across all of them. Once the total exceeded the maximum size of the number used for that calculation, it could wrap around to a much smaller value instead of producing an error.</p>
<p>The engine would still credit the offer owners with their full XRP amounts while charging the buyer only the wrapped-around total. The difference represented newly created XRP, which could then be moved, traded or sent to an exchange like any other balance.</p>
<div style="margin: 24px 0; padding: 19px 22px; border-left: 4px solid #b91c1c; background: #fef2f2; color: #1e293b;">
 <p style="margin: 0 0 8px;"><strong>Why the flaw was serious</strong></p>
 <p style="margin: 0;">The attack did not require a large XRP balance. An attacker could have controlled the accounts placing the offers, paid account reserves and transaction fees, then spread the created XRP across those accounts.</p>
</div>
<h2 id="account-keys-remained-unaffected">Account keys remained unaffected</h2>
<p>The vulnerability sat in payment arithmetic rather than wallet access. Triggering it required hundreds of deliberately priced offers and a transaction designed to consume them together; an ordinary XRP payment or trade would not approach the values needed to create the overflow.</p>
<p>XRPL said it found no evidence of exploitation on a public network, and no private-key compromise, loss of funds or consensus failure was reported. The flaw appears to have been present since the current payment engine was written in 2015, remaining undiscovered because normal activity never reached the arithmetic limit.</p>
<p>The existing protection against newly created XRP also relied on the same kind of addition. It could wrap around in the same way as the payment engine, allowing the transaction to appear normal instead of flagging the unexpected increase in balances.</p>
<h2 id="why-developers-used-an-emergency-deployment">Why developers used an emergency deployment</h2>
<p>Developers released the overflow fix before publishing its technical details because a normal amendment timeline would have left a known exploit available for weeks. The patch shipped in <code>xrpld</code> version 3.4.1 on September 25, while the public disclosure followed on October 9.</p>
<p>XRPL usually changes transaction rules through amendments. Validators first upgrade their software, then maintain the required support for a set period before the new rule activates at the same ledger point across the network. That process avoids situations in which different servers reach different conclusions about the same transaction.</p>
<p>Waiting for that process would have created a difficult problem here. Because <code>xrpld</code> is open source, publishing the repair could have shown attackers where to look while older software still accepted the vulnerable transaction path. The team therefore made the new overflow check take effect when an individual server upgraded.</p>
<p>That faster approach carried a temporary compatibility risk: an unpatched server could have accepted an exploit transaction that an upgraded server rejected. Developers considered that less dangerous than allowing created XRP to enter the market. The report says more than 80% of validators on the default UNL had upgraded on the day version 3.4.1 was released.</p>
<div class="read-more pb-3 pt-3 pt-md-2 px-3 my-4 border bg-light">
 <h5 class="text-uppercase border-bottom mb-3 pb-1 d-none d-md-block">READ MORE:</h5><a href="https://coindoo.com/xrp-ledger-gives-banks-new-wallet-controls/" rel="noopener noreferrer nofollow">
  <div class="contentRight col-4"><span><img src="https://coindoo.com/wp-content/uploads/2026/05/xrp-ripple-coin.jpg"></span>
  </div>
  <div class="contentLeft col-8">
   <h4 class="title mb-0">XRP Ledger Gives Banks New Wallet Controls</h4>
  </div></a>
</div>
<h2 id="the-disclosure-covered-a-second-separate-flaw">The disclosure covered a second, separate flaw</h2>
<p>The report also detailed a validation problem in XRPL’s forthcoming Batch feature, which lets users submit several transactions as one unit. It could have caused servers running different versions of the software to disagree over a malformed Batch transaction, interrupting ledger validation or breaking applications that parse transaction data.</p>
<div style="margin: 24px 0; overflow-x: auto; border: 1px solid #dbe3ef; border-radius: 12px;">
 <table style="width: 100%; min-width: 620px; border-collapse: collapse; color: #1e293b;">
  <thead>
   <tr style="background: #0f172a; color: #ffffff;">
    <th style="padding: 12px; text-align: left;" scope="col">Issue</th>
    <th style="padding: 12px; text-align: left;" scope="col">Potential consequence</th>
    <th style="padding: 12px; text-align: left;" scope="col">How it was addressed</th>
   </tr>
  </thead>
  <tbody>
   <tr style="background: #f8fafc;">
    <td style="padding: 12px;"><strong>Payment-engine overflow</strong></td>
    <td style="padding: 12px;">Spendable XRP created beyond the intended supply.</td>
    <td style="padding: 12px;">Overflow checks added in <code>xrpld</code> 3.4.1.</td>
   </tr>
   <tr>
    <td style="padding: 12px;"><strong>Batch wrapper validation</strong></td>
    <td style="padding: 12px;">Server disagreement, stalled validation or broken transaction parsers.</td>
    <td style="padding: 12px;">The <code>fixBatchV1_2</code> amendment, activated on October 9.</td>
   </tr>
  </tbody>
 </table>
</div>
<p>The Batch flaw was caught before the feature reached mainnet. The overflow issue affected existing payment-engine code, which is why its patch could not wait for a standard activation cycle.</p>
<p>The report arrived while XRPL was also activating <a href="https://coindoo.com/xrp-ledger-gives-banks-new-wallet-controls/" rel="noopener noreferrer nofollow">new account-control tools for businesses</a>. The changes address different parts of the ledger, yet both depend on node operators, wallet providers and developers following the same current rules.</p>
<h2 id="what-users-and-operators-need-to-do">What users and operators need to do</h2>
<p>Regular XRP holders do not need to move funds, replace a wallet or exchange their tokens. The update concerns the software that validates transactions, not a change to account balances, wallet keys or the XRP supply held by users.</p>
<div style="margin: 24px 0; padding: 19px 22px; border: 1px solid #bfdbfe; border-radius: 12px; background: #eff6ff; color: #1e293b;">
 <p style="margin: 0 0 10px;"><strong>Who needs to act?</strong></p>
 <ul style="margin: 0; padding-left: 20px;">
  <li><strong>XRP holders:</strong> No action is required.</li>
  <li><strong>Exchange users:</strong> Follow platform notices if an exchange carries out maintenance on its own XRPL infrastructure.</li>
  <li><strong>Node operators:</strong> Upgrade to <code>xrpld</code> 3.4.1 or later to remain in sync with the network.</li>
 </ul>
</div>
<p>Older servers are now amendment-blocked following the activation of the Batch fix, meaning they cannot continue following the current ledger rules until they update.</p>
<h2 id="the-fix-protected-xrp-s-supply-rules-before-they-were-tested">The fix protected XRP’s supply rules before they were tested</h2>
<p>The disclosure shows how close the ledger came to a supply-integrity failure and why validators moved quickly. The flaw was fixed before its details became public, no exploit was found, and the payment engine now uses checks designed to stop the same class of arithmetic error before it reaches a validated ledger.</p>
<p style="text-align: center;"><em>This article is for informational purposes only and does not constitute investment or technical advice. Node operators should review current XRPL release documentation before updating production infrastructure.</em></p>
<p>The post <a href="https://coindoo.com/xrp-ledger-found-bug-could-create-xrp/" rel="noopener noreferrer nofollow">XRP Ledger Found a Bug That Could Create XRP</a> appeared first on <a href="https://coindoo.com" rel="noopener noreferrer nofollow">Coindoo</a>.</p>

XRP Ledger Found a Bug That Could Create XRP

Table of Contents

Coindoo.com

Other articles published on Oct 10, 2026

Morpho is supercharging Coinbase and Robinhood growth

Ondo officially launches pre-IPO trading.

Litecoin Appears to be under attack

Cardano Breaks Through 125 Million Total Transactions

Ethereum ETF Approval Prediction Market: $2,400 Odds

XRP holder lowers target price, says $15 to $20 more realistic long term

Join our free newsletter for daily crypto updates!