The XRPL Foundation has patched a critical flaw in the Batch amendment before it reached mainnet activation. The issue was detected during the voting phase and was blocked through an emergency software update.
The vulnerability was identified on Feb. 19, 2026, by security engineer Pranamya Keshkamat and Cantina AI’s autonomous tool Apex. The foundation confirmed that no user funds were at risk because the amendment had not been activated.
The flaw existed in the signature validation logic of the proposed Batch amendment, also known as XLS-56. The amendment would allow multiple inner transactions to be grouped into a single batch. These inner transactions were designed to remain unsigned. Authorization would instead rely on the outer batch’s list of signers.
According to the XRPL Foundation, a loop error in the signer validation function caused the issue. When the system encountered a signer for an account not yet created, it could exit early. If the signing key matched the new account, validation was marked successful. The system then skipped checks for the remaining signers.
This behavior created a path for unauthorized transactions. An attacker could execute transactions from victim accounts without private keys. The amendment was still under validator voting at the time of discovery. It had not been enabled on the XRPL mainnet. The foundation stated, “The amendment was in its voting phase and had not been activated on mainnet; no funds were at risk.”
The reported exploit required a carefully structured batch transaction. An attacker would include three inner transactions within a single batch. One transaction would create a new account controlled by the attacker. Another would submit a simple transaction from that new account. The third would attempt a payment from a victim account to the attacker. The attacker would provide two batch signer entries.
One signer entry would be valid for the newly created account. The second would falsely claim to authorize the victim account. Due to the early loop exit, the system could accept the first signer and skip validation of the second. The victim’s payment could then execute without authorization.
The XRPL Foundation stated that such an exploit could have allowed fund transfers and ledger changes. It also noted the risk of ecosystem disruption if widely abused. Cantina and Spearbit CEO Hari Mulackal said, “Our autonomous bug hunter, Apex, found this critical bug.” Ripple engineering teams reproduced the issue with a proof of concept. A full unit test was also completed before remediation began.
Following disclosure, UNL validators were advised to vote “No” on the Batch amendment. An emergency software release, rippled 3.1.1, was published on Feb. 23, 2026. This version marks both Batch and fixBatchInnerSigs as unsupported. As a result, they cannot receive validator votes or activate on the network.
The update does not include the final logic correction. It acts as an immediate safeguard to block activation. A corrected replacement called BatchV1_1 has been implemented. The updated version removes the early exit and strengthens authorization checks. The amendment is under review, and no release date has been set.
Additional safeguards are also planned. The foundation plans to expand AI-assisted code audits. It will also extend static analysis to detect premature success returns in loops. The XRPL Foundation confirmed it has patched the critical flaw before mainnet activation. The early intervention prevented unauthorized transactions and protected network integrity.
The post XRPL Blocks Critical Batch Amendment Bug Before Reaching Mainnet Launch appeared first on CoinCentral.


