XRPL disclosure: the 3.4.1 overflow fix skipped the amendment vote, a first in ten years
Victoria Shinder3 min readWhen xrpld 3.4.1 shipped on 25 September as an emergency release, its notes said only that it fixed security-sensitive issues and that details would follow. The details came on 9 October in a vulnerability disclosure report on xrpl.org, published the same day the related amendment activated and the 3.4.1 source code was released. It covers two bugs. The second is the one that changes how the XRP Ledger has worked until now.
Bug one: Batch inner transactions in the wrong wrapper. The Batch feature (XLS-56) lets an account submit up to eight transactions as a unit. Its specification requires each inner transaction to sit in a RawTransaction field; the server did not enforce that. First logged as a low-severity Attackathon finding and believed fixed, it was found on 18 September to be only partly fixed, and on 22 September RippleX's Mayukha Vadari showed it could also make servers of different versions disagree — raising it to a blocker. Batch had not been activated on Mainnet, so no funds were exposed. Validators, Ripple among them, withdrew their votes for BatchV1_1 to reset its activation clock, shipped the new check as the amendment fixBatchV1_2, then voted Batch back in about 30 minutes behind the fix. Both activated on 9 October, and servers older than 3.4.1 are now amendment-blocked.
Bug two: XRP from nothing. A researcher, credited as Cayden Liao and Veria AI, reported through the bug bounty on 22 September that an integer overflow in the payment engine could create new, spendable XRP. When a single payment consumed a very large number of offers, the running total could exceed what a 64-bit value holds and wrap around, so the payer was charged far less than the offer owners received. RippleX reproduced it the same day and rated it critical. The report says the flaw likely dates to 2015, when the current payment engine was written, and that there is no evidence it was exploited on any public network.
The precedent. Rule changes to transaction processing on the XRP Ledger normally go through an amendment: shipped dormant, switched on only after more than 80% of trusted validators support it for two weeks, so every server changes rules at the same ledger. This fix did not. It took effect on each server the moment that server upgraded — the report calls it the first deliberate change to transaction processing shipped this way since the amendment system was introduced more than ten years ago. The reasoning is stated plainly: an open-source fix reveals the bug, and the amendment timetable would have left it public and exploitable on Mainnet for weeks.
The risk they accepted, and why it held. While servers ran mixed versions, an exploit attempt could have split the network into servers that accepted it and servers that rejected it; ordinary payments never touch that code path. What made the gamble acceptable, the report says, was speed: more than 80% of default-UNL validators ran 3.4.1 on release day, before its source was published. The authors stress that the amendment process remains the rule and that skipping it is reserved for bugs worse than a network halt.
What changes next. Every security finding marked fixed — from audits, bounties or AI red-teaming — is now to be re-tested against each release candidate and closed only when a test reproducing the original report passes. The incomplete Batch fix is the reason.
Source: XRPL.org, Vulnerability disclosure report, 9 October 2026 — https://xrpl.org/blog/2026/vulnerabilitydisclosurereport-bug-20261009 ; earlier coverage of the release — https://xrpl.org/blog/2026/xrpld-3.4.1