A critical flaw emerged after the network was protected

XRP Ledger developers have disclosed a critical integer-overflow vulnerability in the network's payment engine that could have allowed an attacker to create spendable XRP without funding the full payment. The public report, dated October 9, says the bug was fixed in xrpld 3.4.1, an emergency server release issued on September 25. Developers said they found no evidence that the flaw was exploited on any public network.

The disclosure separates the payment flaw from the Batch transaction issue also documented in the same report. The Batch problem concerned transaction wrappers and a potential mixed-version consensus disagreement before that feature reached Mainnet. The payment-engine overflow affected xrpld 3.4.0 and earlier and presented a direct risk to XRP's supply rules.

Related reporting: XRP Ledger Activates Batch Transactions After Validator Vote

How one payment could defeat two checks

The vulnerable path appeared when a single payment consumed many offers from the XRP Ledger's built-in exchange. The engine added the XRP amounts owed across those offers using a fixed-size integer. If the sum passed the maximum value, it could wrap around to a much smaller number rather than failing. Individual offer owners would receive their full amounts, while the buyer would be charged only the wrapped total. The difference would be newly created XRP.

A second safeguard did not stop the test attack. XRPL includes an invariant intended to detect any transaction that creates XRP, but the report says that check added balance changes in the same vulnerable way and could overflow identically. RippleX engineers reproduced the proof of concept on a standalone server and confirmed that the resulting XRP could be spent in a follow-up payment.

Emergency release bypassed the usual amendment path

The researcher submitted the issue through the XRPL Bug Bounty program on September 22. RippleX initially received it as a major finding, reproduced it and raised the severity to critical. Engineers built and reviewed a private fix over September 22 and 23, merged it into the 3.4.1 release branch and shipped the final release two days later.

Unlike ordinary changes to transaction processing, the overflow fix took effect as each server upgraded instead of waiting for the standard amendment vote. The report says this was the first deliberate use of that route for transaction-processing rules since XRPL's amendment system was introduced more than a decade ago. That choice created a temporary risk that patched and unpatched servers could disagree, but developers judged the exploit risk to be worse.

Rapid validator upgrades reduced the transition risk

More than 80% of validators on the default Unique Node List were running 3.4.1 on release day, according to the disclosure. That rapid adoption helped protect the network before technical details and source code for the fix were published. Operators must now run 3.4.1 or newer to remain synchronized; older servers are also blocked by the newly activated Batch fix.

The remediation adds overflow checks to the payment engine and uses a wider counter for the no-new-XRP invariant. The team said it is also adding release-candidate re-verification for every security finding marked as fixed. The absence of known exploitation lowers the immediate impact, but the episode highlights the operational trade-off in decentralized systems: a severe protocol bug can require fast, coordinated upgrades before the community receives a full public explanation.

Sources

AI-generated editorial image; not a photograph of the reported event. Prepared with AI assistance and source verification.