XRP Ledger was about a week away from turning on Batch, a new feature that lets users send up to eight transactions together, when engineers realized a bug previously rated low severity could potentially stop the network from processing new transactions.
- The bug was first found during an audit contest run by Sherlock, a crypto security platform that pays independent researchers to review blockchain code for vulnerabilities before it goes live.
- Developers initially believed the problem had been fixed, but a later check found the fix was incomplete.
- Engineers at RippleX, Ripple's team that works on XRP Ledger software and developer tools, then found the remaining bug could make different versions of the network software disagree over the same transaction.
- Batch hadn't yet gone live on mainnet, so no XRP accounts or transactions were affected
A small bug turned into a network-halt risk
Batch, formally called XLS-56, is meant to let someone send several XRP Ledger transactions together instead of submitting them one by one. For example, a user could send several related transactions and require all of them to succeed together. If one fails, the others can be stopped too.eeed
Inside every Batch, each individual transaction is supposed to carry a specific label called RawTransaction.
But xrpld, the core server software that runs XRP Ledger nodes and validators, wasn't checking that label correctly. Someone manually creating a transaction could use another label instead and still get it accepted.
That alone didn't let anyone steal XRP, forge signatures or spend money they didn't own. Every transaction inside the Batch still had to be properly signed and otherwise valid.
The more serious problem appeared because different versions of xrpld recognized different labels.
- One older version, xrpld 3.3.0, still recognized several labels that were removed from the newer 3.4.0 release.
- A specially made Batch transaction could therefore be accepted by a computer running the older software while a computer running the newer version rejected it.
- That could become a problem for validators, the network operators whose computers compare transactions and agree on the next version of the XRP Ledger.
- If enough validators were running different software versions, some could accept the transaction while others rejected it.
- The network could then fail to agree on the next ledger and stop confirming new transactions until enough operators upgraded.
According to the disclosure, triggering the problem would have cost only a normal transaction fee.
Developers thought they had already fixed it
The bug first appeared as finding F48 during the Sherlock Attackathon, an audit contest where independent security researchers reviewed XRP Ledger code and reported possible vulnerabilities.
And it was rated as low severity. Developers believed the issue had been fixed while preparing BatchV1_1, an updated version of the Batch feature.
- But Denis Angell of the XRPL Foundation, an organization that supports XRP Ledger infrastructure and development, checked the earlier security findings again and found on Sept. 18 that the fix hadn't fully worked.
- Four days later, Mayukha Vadari of RippleX found the bigger risk.
- As it turned out, different versions of XRP Ledger software could disagree over whether the same transaction was valid.
The team then raised the issue from a low-severity finding to a problem that had to be fixed before Batch could go live. By then, BatchV1_1 had already received enough support from validators to begin its activation countdown and was scheduled to turn on Sept. 29.
Ripple and other validator operators then changed their votes to "no," stopping the countdown before the feature could activate. The same transaction could also break wallets and explorers.
Several widely used XRP Ledger software libraries, including versions for JavaScript, Python and Java, were built on the assumption that every Batch transaction would use the correct RawTransaction label.
Those libraries are used by developers to build wallets, exchanges, websites that display blockchain transactions and other apps connected to XRP Ledger.
A specially made Batch transaction using the wrong label could therefore cause some of that software to fail when trying to read it. And if such a transaction had been accepted by the live network, it would have stayed permanently in XRP Ledger's transaction history.
Developers would then have needed to keep special handling in their software for that malformed transaction instead of simply removing or editing it later.
The bug couldn't happen through a normal wallet or standard XRP Ledger app. Someone would have had to manually build the transaction specifically to trigger it.
Batch eventually went live after another fix
Developers created fixBatchV1_2, a separate XRP Ledger update that forces every transaction inside Batch to use the correct label.
- The fix shipped in xrpld 3.4.1, a new version of the XRP Ledger server software, on Sept. 25.
- Validator operators then resumed supporting Batch, but the timing was arranged so the security fix would activate first.
- Both updates went live on Oct. 9, with fixBatchV1_2 activating before BatchV1_1.
According to the disclosure, the bug never reached Mainnet. No funds were lost, no incorrect transactions were processed and XRP Ledger didn't halt.